> > Face it, we _already_ have more than one side band.
>
> Wouldn't it be natural to
> write(fd, <control type>)
> write(fd, <control information)
> read(fd, reply)
>
> Only one control file for all controls a device understands
That's one of the ways to do it. However, it's less than ideal when
you want to mix access to such channels. Again, look at font and
screen contents of VC. You can force everything into that model.
It even makes sense for many cases. Not all of them, though and
any solution for the rest will handle the special case.
Example of such solution (_not_ for sockets - they are very different)
readlink() on /proc/self/fd/<n>, then replace everything past
the last /. BTW, that way you can bind a device into chroot jail, but
leave some subset of channels out of it. Or all of them. Just don't
bind the side channels there.
> > Moreover, we have channels that are not tied to a particular device -
> > they are for a group of them. Example: setting timings for IDE controller.
> > Sure, we can just say "open /dev/hda instead of /dev/hda5", but then we
> > are back to the "find related file" problem you tried to avoid.
>
> If the IDE controller is a device we can control, it should have a device
> file and a control device file.
>
> Problem solved, AFAICS.
Sure, but the same logics applies to /proc/self/fd/<n>/ioctl. Yes, sometimes
you need to figure out the name of related file. Depends on situation.
Saying that we have one very special related file that corresponds to current
ioctls looks rather bogus.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/