Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 4 Feb 2002 00:19:13 -0500 (EST) | From | "Calin A. Culianu" <> | Subject | Re: Asynchronous CDROM Events in Userland |
| |
n 3 Feb 2002, H. Peter Anvin wrote:
> Followup to: <Pine.LNX.4.30.0202032333200.1158-100000@rtlab.med.cornell.edu> > By author: "Calin A. Culianu" <calin@ajvar.org> > In newsgroup: linux.dev.kernel > > > > > > Is there any way, other than by polling, to have a user process be > > notified of a change in status on a cdrom drive? (Such as if the drive > > opens, closes, gets new media, etc)? > > > > Also, come think of it, other types of asynchronous events would be nice > > too, like when a cdrom usb device gets hot-plugged into the system, etc. > > > > The current ioctls are inadequate for this type of thing (they are > > synchronous in nature). One nice thing would be if we can register SIGUSR > > or other types of signals with the cdrom driver(s) so that it can notify a > > user process of (cdrom) events it may be interested in. > > > > The reason I ask this is that the current autorun program that comes with > > kde is very inefficient because it polls the cdrom drives. Also, this > > program is completely unable to determine that a usb device has come > > online, because it basically can't differentiate between bogus /etc/fstab > > entries and offline usb devices. > > > > At any rate, if anyone can suggest a way to asynchronously receive cdrom > > events in userland, it would be appreciated. > > > > If not what do you guys think about extensions to the cdrom drivers to > > handle these types of things? > > > > Rather than a signal, it should be a file descriptor of some sort, so > one can select() etc on it. Personally I can't imagine polling would > take any appreciable amount of resources, though.
Yes, select()ing on it would be more useful, but I don't know if this would clash with existing semantics, because currently select() on a set of readfds that are cdrom drives always returns right away (I am not sure why this would be, as if you open /dev/cdrom with O_NONBLOCK|O_RDONLY you are supposed to be doing ioctls and no actual reading, no?).
Maybe such events can be in the exception fds?
-Calin
> > A more important issue is probably to get notification when the eject > button is pushed and the device is locked, so that it can try to > umount and eject it, unless busy. > > -hpa > > >
- 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/
| ![\](/images/icornerr.gif) |