> > Source code:
> >         sys/sys/usb.h
> >         sys/sys/usbhid.h
> 
> Why aren't these in sys/dev/usb or someplace similar?  ("Just because
> some other headers are broken..." 8-)
I don't really care where they live, but they need to be
installed so that they are accessible from user-land.
Since sys/sys seems to be where these files generally live
I thought it was the right place.

> > Hub driver.  There must always be a hub driver since all USB systems
> > have at least one hub (the root hub).  The hub driver is responsible
> > for connecting and disconnecting devices and also handles to bus
> > enumeration and probe/attach.  Even though devices physically
> > attach to a hub the logical attachment is still to `usb?'
> >         sys/dev/usb/uhub.c
> 
> If it's always there, why is the root hub part of the
> autoconfiguration machinary, as opposed to being glued directly into
> the bus code?  I can see some modularity reasons for wanting to do it
> that way, but on the other hand if it's _required_...  (e.g. the ISA
> controller DMA code doesn't show up as a separate device...)
The only reason is consistency, every hub shows up in the 
autoconfig machinery.  I could easily dispense with the top
level hub (In fact that was the way it as before), but this
looks more logical.

> What other kinds of hubs are there, and how are they used?
Hubs are fan-out boxes and comes an all shapes and sizes.
One cable in, several cables out.  The USB "bus" is physically
a tree and hubs are the way the tree branches.
Your keyboard will probably have a hub, as will your monitor,
so you can easily plug in other devices.  You can also
buy little boxes that are hubs.  Hubs can either be powered
from the bus or by an external power source.
The root hub can be thought of as the first branching point of
the USB tree.
So the hub driver is needed at the root and you will most likely
need it elsewhere as well.

> What are the interactions between device and interface drivers?  Is it
> possible for a 'device' driver to claim a device in its entirety, to
> prevent 'interface' drivers from attaching?
Absolutely.  First the autoconfig code tries to match 
device drivers (which can match at several priority
levels).  If no device driver claims the device the config
code then enumerates the interfaces and checks if there
are any matching interface drivers (again with several
priority levels).  If none of the interfaces are claimed
there is one final chance for a totally generic driver to 
pick up the device.

> i think something like:
> 
>      uhub* at usb?	# hub device driver
> 
>      udev* at usb?      # generic device driver; attaches interfaces
> 			# as subdevs.
> 
>        ums* at udev?	# interfaces.
>        ukbd* at udev?
>        uaudio* at udev?
>        uhid* at udev?
I've been thinking about this design as well, but I don't
see any advantage of this design right now.  But there
might be.  
There are some weird devices (like my speakers) where you need a
device driver because audio devices have two interfaces that need to
be used together (the Audio Control (i.e. mixer) and Audio Streaming
(i.e. data) interfaces) so you can't attach them as interface drivers.
But the device also has some buttons that appear as a HID
interface.  I've not figured out how to handle this the best
way yet.



> > In /dev some new devices are needed:
> > /dev/usbN               The device the usbd demon talks to for
> >                         handling connect and disconnect.
> > /dev/uhidN              Generic HID devices, supports reading and
> >                         writing to the device as well as ioctl
> >                         to get descriptors.
> 
> these are per usb bus, and per hid interface, respectively?
Yes.

Thanks for your feedback.

        -- Lennart