> 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/