> You have a PCI device that is the USB controller. You create a child of
> that represents the USB bus. Then, devices are added as children of that.
>
> Logically, couldn't you skip that extra layer of indirection and make USB
> devices children of the USB controller? Or, do you see benefit in the
> explicit distinction?
Since I don't see a benefit from that extra indirection, I was going to ask
almost that same question ... :)
But it's broader than that: Why shouldn't that apply to _every_ kind
of bridge, not just USB controllers ("PCI-to-USB bridges")?
For example, with PCI why should there ever be "pci0" directories,
with children "00:??.?" and "pci1"?
> ... A 'bus' is simply a device that has children.
>
> This concept is something that I have argued both for and against since I
> started on this. Initially, the goal was to separate the two because they
> followed such different semantics.
>
> But, I've found it, IMO, it creates more problems than it solves. ...
If the model that driverfs exposes is that directories denote devices
(of any type including bridge) and (text) files expose device properties,
then my initial suspicion is that the additional level of indirection would
not be necessary. Maybe some "type" property would be desirable
though, to better separate namespace structure from typing issues.
(It might need to be provided by the device/bridge driver.)
When I've seen corresponding problems in other areas, the extra
indirection has not been necessary. The simpler naming policies
have been a lot easier to work with.
I suspect it'd be better to simplify the naming policy for bridges and
busses everywhere in driverfs, not just for USB, but I'd like to know
any arguments for keeping that extra level of indirection.
- 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/