On Sun, 17 Jun 2007, Dave Mielke wrote: > [quoted lines by Alan Stern on 2007/06/17 at 17:07 -0400] > > >I'm not sure what you're asking. Do you want a usbfs interface which > >provides the same capability as the sysfs interface? > > Yes, except that the setting would be just for the close of the file > descriptor.
You mean sort of "remember the previous setting, store a 0, then when the file is closed reinstate the old setting"? Sounds cumbersome and prone to failure. > >So I don't see anything wrong with simply using the sysfs approach. > > The only reason I'd still raise is that it's usually nicer to use a temporary, > rather than a permanent, setting. In your case it shouldn't matter, since you never want the device to be suspended. In fact, is there any reason why your users don't simply leave brltty running the entire time the computer is on? > A few more qeustions, if I may: > > Right now we search for the device by going through /proc/bus/usb/, one device > at a time, opening it, reading the device descriptor, and then either using or > closing it. Does htis mean that we're needlessly resuming/suspending all the > devices? Yes. Not that it matters much; there's nothing wrong with resuming a device every now and then. Normally it would go back to sleep in a few seconds. > How does lsusb do it? Exactly the same way you do. In fact any program using libusb (which includes lsusb) will have the same effect, because libusb itself follows that procedure when it starts up. > Should we be querying the device via sysfs > instead even though it means a lot more open/read/close system calls? Doing so would avoid the resume/suspend cycles. But I would say it's not worth the effort to convert over, if that's your only reason. If you were starting fresh with a new program then using sysfs would be the best way to go. It's not all that many more open/read/close calls, and they are completely internal to the kernel anyway so they run extremely quickly. > Is it guaranteed that the current value in .../power/autosuspend will have > been > read when the close() returns or might the final stages of closing the device > occur somewhat later? In other words, is there a possibility that we'll be > defeating ourselves by restoring the original value right after the close()? It sounds like you don't understand exactly what the value in power/autosuspend does. The number is an autosuspend delay, in seconds. By default it is equal to 2, which means that the device would be autosuspended 2 seconds after its usbfs file is closed or the device is in some other way no longer being used. In 2.6.21 a value of 0 means never autosuspend, but in 2.6.22 a 0 means autosuspend immediately after the close and -1 means never autosuspend. So if you close the file and later write 2 to power/autosuspend, that means the device will be autosuspended 2 seconds after the write instead of 2 seconds after the close. This probably falls into the category of defeating yourself. :-) > Is there any kind of damping in the system to prevent problems/overload if a > device is opened/closed too often too close together? Yes; the fact that the value is normally set to 2 does exactly that. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
