Messages in this thread | | | Date | Wed, 30 Jan 2002 12:07:26 -0800 | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: [PATCH] driverfs support for USB - take 2 |
| |
"> " == "Greg KH" <greg@kroah.com>
> I completly agree.
As I see -- some mailer daemons were adding delays and fomenting confusion!
> However, the root hub name _does_ propose a problem. I feel we have two > solutions: > - use the bus number (usb_bus_00x) > Pros: > matches the usbfs naming and directory structure > Cons: > depends on the initialization order of the busses.
At this point, I'd propose that "driverfs" should adopt a policy that naming dependencies on initialization order are a virus that should be obliterated to the degree it's possible ... which in this case is completely! :)
> - use a generic name like I did (usb_bus) > Pros: > does not depend on the init order, and relies on the > location in the entire pci topology tree to show its > uniqueness. > Cons: > boring :)
Or a third option is to get rid of the extra level of indirection in the current driverfs naming policy, as Patrick suggested in a separate email. I'll follow up separately.
> And also remember, the status file in a device's directory also provides > a _lot_ of information. We haven't even started to fill up the fields > there...
And there can be a lot more such files. Though that 4KB limit may become an issue at some point.
What sort of USB information were you thinking should show up? Current configuration and altsetting? Power consumption for hubs (not that we budget that yet :)? There really aren't any examples of this in the kernel yet.
Also, one could argue that each USB function ("interface") should be presented as an individual device, just like each PCI function is handled ... after all, USB drivers bind to interfaces, not devices, and this is the "driver" FS! :)
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |