Re: [9fans] USB developments

[Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>]

> I think we'll need a database of those anyway, could we use someone's
> hospitality and list the usb/usbd debug output and whoever may have
> an interest in that particular entry (a little like /lib/vgadb) on
> a globally accessible server?

Sure. I'm willing to open accounts here, although perhaps sources is
a better place to do that.

> We'll also probably need a /lib/vgadb definition file for all the
> quirks that USB devices seem to suffer from (I have a document that
> covers foibles in CBI devices, a google find I'm sure I can repeat).

After taking a look to it all, I ended up thinking that the scheme should
be like:

#U, does mostly what it does, but stays appart of csp definitions.
usbd: simply configures the device and reads a usbdb file to
learn which program is to be used for each csp.
usbd: starts those programs when a new csp is noticed.
drivers: are started always on a particular target, and work just
for a particular device.

All of it started at boot time.

For example, we have to keep an ugly sleep in boot.c to give
usbd some time before usbhid starts. It would be better the other way.


>
> I would like to set up a special interest group, if that's OK with
> anyone else who's interested, but not really a separate mailing
> list unless the traffic starts swamping other interests here.

Yep. Better keep on using 9fans. There's no need for a separate list.

> Nemo, you're much more familiar with the kernel code, could you
> look into the bit I suggested, where a USB utility merges a kernel
> function (ATA is my immediate interest) with the USB device,
> analogously to the ip/ipconfig does?  I'll be thrilled to implement
> the ideas, if you can set me on the right track.
>

I'd just modify usbd to start the driver when a device is first seen,
then the driver can be responsible for killing himself, should the device
go away. If the device comes back again, usbd could start the device
again.

Isn't that enough?