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. This suggests that usbfs2 should have special "interface" files as well as a special "device" file and "endpoint" files. 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. > Oh, have you seen the 'drivers_autoprobe' and 'drivers_probe' stuff for > the bus directories in sysfs that are in the -mm and my tree? That > would also allow this to work pretty easily through sysfs, as HAL will > soon be able to control almost all of the binding and unbinding of > devices to drivers, something the distros have wanted for some time now. Ah. I had noticed it some time ago but never looked at it very carefully. It looks good, and it should be very useful. > > > > Release (unbind usbfs from) an interface. > > > > > > Use sysfs > > > > Likewise here. > > See above :) Actually this _would_ work. When the disconnect() method runs, of course usbfs will know which open file handle is already associated with the interface. > > 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/ 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"! 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-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
