> > 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. > > Then what is sufficient ?
The basic problem is that both "physical" (hardware based) and logical (function based) names are needed. They serve rather different purposes. System management tools (yes, poorly supported under Linux at best) need to work with both kinds of names. Fixing a problem like "logical device X isn't working" may need someone to figure out which physical devices are involved, and vice versa... I'd say that anything that doesn't expose a bi-directional mapping between those layers of name isn't sufficient. Maybe more is needed, too. > > > 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. > > By a naming scheme like the one devfs uses for disks ? I don't use devfs; the last time I tried, it oopsed, which was a bit of a downer. So I don't know what you mean. Root hubs need stable names -- the PCI slot/function name would normally work well, but the "bus number" isn't good. It'd be simple to change "usbdevfs" to use those names instead of bus numbers. And rather than using address-on-bus to identify devices, the path from the root hub is better. The hub driver prints out such an identifier if you tell it to be verbose: A/B/C where those numbers identify ports on the hub. It'd be simple to make "usbdevfs" save those strings and use them for its identifiers, likely changing "/" to "." (or something) so that directories behave. As I've noted before, integrating USB with the "device fs" (in 2.5, though I've not looked at it yet) would likely hit some of those issues. And it might well _need_ to make those A/B/C style names be real directories, to make power management behave consistently. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
