[ I've briefly glanced through a book about USB, but that's the extent
  of my knowledge about it.  Thwack me if i'm clueless. ]

> The NetBSD USB driver is done in several layers (just like SCSI
> and PCMCIA).
> The following header files are derived from the USB specs and
> are used by kernel and user code.
> 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-)


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

What other kinds of hubs are there, and how are they used?


> There are actually two kind of USB devcie driver, device drivers
> and interface drivers.  A device driver recognizes a USB device as
> a whole unit (could be based on product/vendor codes, but could
> also just be based on the device class).  An interface driver
> attaches to a specific interface on a device (of which there may be
> many) based on the interface class.  The hub driver is a device
> driver and the rest are interface drivers.  So a physical USB device
> which is a keyboard with a built in touch pad would present two
> interface and it would get both a keyboard driver and a mouse driver
> attached to it.

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?

You typically want to do this when you've got a specific driver that
handles a device specially, as more than the sum of its components.
I've seen places where drivers would want to do this with the SCSI
code (in particular, claim the entire target, regardless of LUNs), but
our SCSI code currently can't do it (easily; cleanly).  It'd be nice
if the USB code got this right, but looking at your autoconfig code
spec it doesn't look like it does.  8-)


> So this is how the attachment could look
> 
> uhci0 at pci0           Host controller
>   usb0 at uhci0         The "bus"
>     uhub0 at usb0       Root hub
>     uhub1 at usb0       Other hub
>     ums0 at usb0        Mouse
>     ukbd0 at usb0       Keyboard
>     uaudio0 at usb0     Speakers
>       audio0 at uaudio0
>     uhid0 at usb0       Joystick
>     uhid1 at usb0       ...

What are the locators for these devices?

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?

may be better, for the reason outline above.


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





cgd