Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re <lucio@proxima.alt.za>]

On Thu, Jan 15, 2004 at 08:24:12PM +0000, Charles Forsyth wrote:
> otherwise, for a real hub, you must periodically
> use a USB transaction on the hub's control endpoint to poll for changes
> to the status of its ports.  there is no code in the existing driver to
> poll, but that's precisely because it leaves that to usbd, which anyway
> needs to poll for other changes in configuration.
>
I assumed polling would best be a kernel function, but I can see
that there are different views.  I'll go along with usbd doing it,
it seems most appropriate here.

> you need the tree structure because that reflects the physical connection
> structure.  when a hub goes, it takes all the connections through it,
> including directly-connected devices, other hubs, their devices, and so on.
>
I have to agree.  My assumption was that usbd would do that, on #U
reporting that there has been a change.  You make a very strong case
for it not working.

> i just don't see why it's so important to you that the kernel enumerate
> (if it doesn't configure, and if it does configure, it needs to know much
> more about the class, and since classes are often 0, the device).
>
I'm not sure why it was so important, but it may come back and bite
me.  Still, your arguments are presently unassailable.

> >>or serial numbers etc. becomes too painful.  Keep in mind that XP
> >>deals with it, why shouldn't Plan 9?
>
> because many manufacturers write special USB drivers that
> deal with the peculiar/proprietary protocol used by their device!
> it's no different in that regard from VGA (or VESA)
>
No, no, no.  I'm thinking USB here, not function.  I suppose there
may be hubs that are also broken, but these are all special cases,
they mustn't get mixed up in the minestrone.  My beef is that I
want the bus management to match the specs as accurately as possible,
on the assumption that the bus is OK.  Device drivers, quirks and
databases will handle functions and all their foibles.  It should
not be necessary to alter the bus drivers to deal with them, except
perhaps to implement the quirk - but at least it's then a few
generic operations, not a mass of special cases.

> >>believe that brocee's work should be reconsidered.  Specially if
>
> it has been, but that's not really a key to this discussion.
> it might indeed be useful to load USB-device-specific modules into
> the kernel, in the same way that Etherif components might be loaded,
> but that doesn't seem to me to be the determining aspect.
>
See, you agree with me :-)

> ... since the printer
> now is usb0/3/ep2data but in a little while it's usb1/2/ep2data,
> depending on which USB slot on my thinkpad i chose.
> (in fact, for USB it's worse because the /2/ and /3/ there are
> dynamically assigned and unpredictable.)
>
Yep, a point I could have made, had I thought things out instead
of shooting from the hip.  Again, the database should contain enough
information to give various devices sensible prefixes or suffixes
and the daemon can assign them instance indices which might suffice.
A naming scheme is nothing more than a naming scheme, /lib/ndb can
deal with local conventions.

> that's possibly where a link to (something like) plumbing might
> be relevant because it might be adequate to be able to say
> `if there's a printer on the USB bus, that's the one' or even
> `if there's an HP printer, that's the laser printer, but
> if there's an Epson that's the photo printer'.

Plan 9 is a little too tightly coupled to its conventions, but I'm
sure the naming scheme will soon settle into something workable
for most and flexible enough for the few exceptions to be managed.

++L