On Mon, Apr 23, 2007 at 06:24:52PM -0400, Alan Stern wrote: > On Mon, 23 Apr 2007, Greg KH wrote: > > > > > > Find out the name of the driver bound to an interface; > > > > > > > > Use sysfs > > > > > > A little tricky, since it involves parsing the last component of a > > > pathname stored in a symlink, but doable. > > > > $ basename `readlink -f /sys/bus/usb/devices/1-6.2:1.0/driver` > > usbhid > > > > Not that tough :) > > Okay -- not tough but tricky! :-) > > > > > > > Claim (bind usbfs to) an interface; > > > > > > > > Use sysfs > > > > > > Again, it can't be done. You can use sysfs to bind a kernel driver to an > > > interface, but you can't use it to bind a userspace program the way usbfs > > > allows. > > > > Well, if we allow usbfs2 to "bind" to any type of usb device, this can > > be pretty simple to add. Even if we don't do that, it only takes 2 > > lines of shell to allow that to happen. > > But when usbfs binds a userspace driver to an interface, there's more > involved than just telling usbcore and the driver core that usbfs is the > interface's driver. Internally usbfs needs to know which open file handle > should be associated with the interface. It won't have that information > if the probing and binding is done through sysfs.
True, but the kernel will know the list of files that have the endpoints open, which is all that we really care about. > This suggests that usbfs2 should have special "interface" files as well as > a special "device" file and "endpoint" files. Nah, I don't think that will be needed. > Trying to implement a full-fledged USB driver in userspace will still have > certain limitations. In particular, we don't have any analog to the > various method callbacks in struct usb_driver. So a user program > doesn't have any way to know if someone is about to suspend the device, > or if it has been forcefully unbound from its interface. Yes, you loose those kinds of notifications, but hey, that's one of the trade-offs you have when working in userspace, it's all a balance :) > > > The hardest aspect is matching up pathnames in usbfs with the > > > corresponding pathnames in sysfs. Going from a usbfs name to a sysfs > > > path can be accomplished by looking in /sys/class/usb_device. The other > > > direction is a little harder. We have a "devnum" attribute but not a > > > "busnum" attribute. Should I add one? > > > > Isn't that implicit from the USB device id number? I'm sure there's a > > "simple" bash script that can get the bus number from the device id... > > Hmmm... I seem to recall at one point you and I were on opposite sides of > this same question. It was about the bEndpointAddress attribute in the > usb_endpoint class directory, remember? I said the endpoint address was > implicit in the directory's name, and you said that nevertheless shell > scripts preferred to read such values directly from attribute files, and > that it helped udev. > > On the other hand, maybe it doesn't really matter. Looking again, I see > the device's directory in sysfs contains a symlink to the class device: > > lrwxrwxrwx 1 root root 0 Apr 23 18:11 usb1/usb_device:usbdev1.1 -> > ../../../../class/usb_device/usbdev1.1/ I don't see that in my system, with CONFIG_SYSFS_DEPRECATED and CONFIG_USB_DEVICE_CLASS disabled... > That ought to be sufficient. Although shell scripts might also find it a > bit tricky to go from "usbdev1.1" to "/proc/bus/usb/001/001"! With CONFIG_USB_DEVICE_CLASS, the usb1 device itself has a "dev" file which is the usbfs major:minor node. Also note that distros are now using /dev/bus/usb/ instead of /proc/bus/usb/ but yes, the naming below that is the same. And I'm not all that set against having a busnum in the device directory, feel free to send me a patch, especially as you brought up my old position :) thanks, greg k-h ------------------------------------------------------------------------- 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-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
