Re: Asynchronous CDROM Events in Userland

From: Calin A. Culianu (calin@ajvar.org)
Date: Mon Feb 04 2002 - 00:19:13 EST


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/



This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:31 EST