Re: USB state change notification to user space
Johannes Erdfelt (jerdfelt@sventech.com)
Sat, 4 Sep 1999 21:42:39 -0400
On Sat, Sep 04, 1999, Drew Bernat <abernat@zathras.net> wrote:
> On Sat, 4 Sep 1999, Johannes Erdfelt wrote:
>
> > I'd like to offer a way for user level programs to be informed of state
> > changes on the USB bus. (ie device plugging in, device unplugging, new
> > bus registered)
> >
> > I can think of a couple of ways to provide this, but I'm unsure what
> > would be the favored way of doing it.
> >
> > 1) opening /dev/bus/usb and poll'ing on read, then rescanning the
> > /proc/bus/<busno> directory to find the change. Kinda weird doing file
> > type things on a directory tho
> > 2) opening /dev/bus/usb/devices and poll'ing on read, then rescanning
> > the /proc/bus/<busno> directory to find the change
> > 3) opening /dev/bus/usb/devices and use a blocking ioctl
> >
> > I can't think of anything which is similar enough in the kernel that I
> > could mimick.
>
> A fourth possibility is some sort of signal, which makes sense in a way --
> do we want the application to a) ask if there is a new device, b) wait for
> a new device, or c) be notified that there is a new device? It wouldn't be
> hard (I think) to write a callback function for the USB handler that an
> application can register with (i.e. a signal). It seems to me that option
> c) is the best, since it maps to the bus behavior best.
Obviously, c) is the best, however it's difficult to do with signals.
Allocating a signal specifically for this is kind of a waste. Are you
thinking perhaps registering which singal should be raised by an ioctl?
I was hoping to get something similar to c) with a poll interface. That
way it can block in poll or poll the fd along with other fd's the
program may need.
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/