Re: [linux-usb-devel] Re: [PATCH] driverfs support for USB - take 2

[David Brownell]

> > And there can be a lot more such files.  Though that 4KB limit
> > may become an issue at some point.
> 
> I doubt it, we are talking one value per file here.  I can't see any USB
> driver wanting to go over 4Kb for 1 value (and if it does, I'll change
> it :)

I could see descriptors getting that large, particularly if
they're turned from binary form into text.  I seem to recall
Patrick was anticipating troubles with that 4K limit, at
some point.

> > 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!  :)
> 
> No, I'll say that we need to stay one physical device per device in the
> tree. 

But we aren't that way today.  Examples:

    - Take a multifunction PCI card ("physical device") and plug it in.
      Each function shows up as another "logical device" in the tree.
      Each such logical device gets one driver.

    - Take a composite USB device ("physical device", like a keyboard
      with hub) and plug it in.  Each logical device shows up separately.
      Each such logical device gets one driver.

The issue with USB is that it's got a much more complex configuration
model, not all of which is well supported yet in Linux.   There's a type
of device which is handled inconsistently:

    - Take a multiple-interface USB device ("physical device") and
      plug it in.  It's presented as one logical device.  BUT (!!) such
      devices need MULTIPLE drivers!!  (Example:  speaker with
      built in volume control, needs audio and HID drivers.)

I was observing that we have a chance to make things consistent.
In my experience, that's normally a good thing.  Similarly, I think USB
should handle configurations more as first class entities.  Changing
a device's config doesn't trigger driver rebinding, for example; we're
in luck, so far, that most devices don't have many configurations.

>     If you want to do an interface tree, let's put that in usbfs,
> where it belongs :)

Ah, but changing usbfs is impractical at this point since lots of
userspace programs rely on it not changing.  Which is why I
was pointing this out in the context of driverfs, which can still
be improved in such ways ... "usbdevfs" was always advertised
as "preliminary", anyway! :)

- Dave