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

[Charles Forsyth <forsyth@terzarima.net>]

>>Let's see if our paths will cross.  Kernel enumerates based on
>>notification (an interrupt, perhaps?) that the structure has changed.
>>Am I reading the spec right that enumeration is the only way to
>>determine the structure and that it should occur frequently?  That's
>>certainly what it sounds like, I'm assuming that instead of polling
>>one can wait for interrupts, but whichever applies, the code is no
>>doubt in the existing driver code already as there is nothing optional
>>about it.

no.  in UHCI you can get interrupts for the notional `root hub' but
that's because it's notional.  it's not a USB hub.  you can't talk to
it as though it's a USB hub.  there are some strange registers.
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.

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 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).

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

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

the naming problem isn't that usb1/2/ep3data (say) is a funny name:
at that level it's as good as any other existing one (eg, eia0, sdD0).
the trouble is that for hardwired devices,
it's not too bad to name them by physical
connection (and that's to some extent unambiguous), since it's
long-lived enough to associate with some higher-level notion
(eg, my printer is on lpt0), but
for dynamically-connected devices, the physical connection name
is still unambiguous, but much less useful, 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.)

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'.