[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Questions about /dev/usb and /dev/usb[0-8]
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
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 van Buul - pino%dohd.org@localhost
Main Index |
Thread Index |