> I don't know of anyone using the usbdevfs interface on devices that have > a kernel driver associated with it. Does anyone else?
Well, it's the clean way to construct the device tree in userland. Parsing the "devices" file is problematic in various cases. In general, when the questions involve mapping hardware (as exposed by "usbfs" :) to logical devices (as exposed by kernel drivers, and in some cases by smart enough apps), or vice versa, neither "usbfs" nor the kernel driver is currently enough. > I've been playing around with a replacement for usbdevfs that removes > all of the ioctls, and just exposes the endpoints for people to read and > write to, much like the *BSD people did. driverfs is great for playing > with these types of experiments :) In fact I also want to see the USB device tree exposed using better names -- as in, ones that expose the device tree, hubs in their proper places, instead of being based on unstable device addressing. > > How are we going to support driverfs ? On the device driver level ? > > Generically ? Both ? > > At first cut, the usb core will use it (I have to see how the pci core > uses it first, to get an idea of what we should do.) It also provides a > lovely place where the individual device drivers can put configuration > options and other useful things, and that will be up to the individual > driver authors to use or not. And the hub driver, as part of the usb core, should also use it... again, to expose the actual device tree, support stable device naming, and support power management ... :) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
