Re: Problem with ioctl command TCGETS

[Al Viro <viro@parcelfarce.linux.theplanet.co.uk>]

On Sun, Nov 28, 2004 at 03:30:19PM +0100, Tomas Carnecky wrote:
> You mean.. like nvidia?
> /dev/nvidiactl
> /dev/nvidia0
> /dev/nvidia1
> /dev/nvidia2
> and do read/write on /dev/nvidiactl (instead on ioctl)?

Really depends on situation - in some cases that's the obvious clean
variant, in some you might want something more specific.  Usually
it helps to ask "what object am I working with?" and see if it gives
a reasonable picture.  Note, BTW, that your example (eject) actually
demonstrates what kind of ugliness can be created by piling everything
together - the logics around "it's currently used, do not eject and
return -EBUSY" is broken and unfixable in all cdrom drivers.  Broken
exactly because we need to open device itself to issue eject request.
Think what happens if we get
	fd = open("/dev/cdrom", 0);
	if (fork()) {
		read a lot from that sucker
	} else {
		sleep for a while
		ioctl(fd, CDROMEJECT, 0);
	}
>From the driver point of view, we have only one opener.  There's no way
to tell how many processes might have file descriptors that point to
what we'd opened back then.  So we either need to keep track of all
changes in descriptor tables and provide exclusion between that and
ioctls (have fun) or admit that driver might be hit with eject in the
middle of IO, all logics along the lines of "it's opened by somebody,
no eject for us" nonwithstanding.

And then there are horrors like cciss special-casing the open of 1st disk
on a controller (even if there's none) so that we could talk to controller
itself (in particular, tell it to go look for disks that might be attached
to it now).  It gets very ugly; same for RAID array creation, same for
loop device setup and races around it, etc.