[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum

On Sun, 20 May 2001, [iso-8859-1] Jakob ьstergaard wrote:

> > 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.121 / U:1.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site