Messages in this thread |  | | Date | Sun, 20 May 2001 11:42:49 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 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 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/
|  |