Questions about /dev/usb and /dev/usb[0-8]

[Martijn van Buul <pino%dohd.org@localhost>]

Hi,

I've got some questions regarding the interface of /dev/usb (event
notification device) and /dev/usb[0-8] (the controller devices). As a bit
of a background, I'll briefly outline what I was trying to do before
I'll be coming to my point :)

I've got a USB printer, a HP Laserjet 1018, which needs to have its firmware
"printed" to it every time it starts up. The Linux router I'm trying to 
replace uses a hotplug script for that, but since NetBSD doesn't have
anything of that sort I was writing a small daemon to do that job by 
monitoring /dev/usb for that specific device to register. In addition to 
that, it would scan the USB busses at startup to see if it was already
present. Even though my project is currently on halt due to problems with
ulpt (see my post to netbsd-users), I encountered a few oddities about the
API that I don't quite understand (and which are unrelated to my problem):

* /dev/usb can be opened only once, and I don't see why. It's not a real
  device, it's a pseudo-device, and as far as I can see it's stateless,
  and can only be opened for reading. I don't see the problem of having
  more than one program monitoring it for events. Why won't it?

* There is no way to *cleanly* locate all devices on a given USB bus,
  other than probing wildly until you find something. Even though the
  root USB hub is more than likely on address 1, there's nothing in the
  manpage that will guarantee this - in fact, it's stating that address
  allocation is arbitrary. I went to see how usbdevs does this, and quite
  frankly I was a bit disappointed, as it's crude and certainly not up
  to the standard I came to expect from NetBSD:

  - it iterates over all addresses that it hasn't seen yet, starting at 1.
  - If it doesn't get an error, it will start recursively iterating the 
    device tree from there, using the obtained information, marking off 
    addresses it encounters along the way.
  - Once done iterating, it will continue scanning where it left off, until
    it reaches MAX_USB_DEVICES (128)

  This only works because the root USB hub is probably at 1 (I've never
  seen it anywhere else, really), since it will be the first device to
  be hit, and the bus will be iterated correctly. After that, its wild
  probes will only hit nonexisting devices, or devices it has already
  encountered.

  If the root USB hub is on a *different* address for some reason, this
  will no longer be the case. There's nothing that guarantees that devices 
  near the root of the tree have a lower address than leaf nodes. At the 
  very least, this is not documented. This means that it's possible that 
  the linear scan will hit a random branch *before* it hits the root. 
  Even though it won't list devices twice, it still means that devices 
  end up in the wrong place. 
  
  I'm aware that the implementation of userland processes is off-topic here,
  but it seems to be caused by a deficiency in the API. If /dev/usb[0-8] 
  could just tell what the address of the root USB hub is (more than likely:
  1), there would be no need for a weird hit-or-miss scan.

* the usb_device_info struct can hold several device names, but doesn't
  mention how many are valid. 

If someone could enlighten me (especially regarding the first two), I'd
be obliged :)

Thanks in advance,

Martijn
-- 
Martijn van Buul - pino%dohd.org@localhost