Messages in this thread | | | Date | Sat, 4 Sep 1999 21:42:39 -0400 | From | Johannes Erdfelt <> | Subject | Re: USB state change notification to user space |
| |
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/
| |