> You never mentioned what locators the various devices use.  It's
> important to have those well-defined, and to have your config scheme
> structured such that somebody can uniquely identify and hard-code the
> identities of devices on their busses.  (Given the nature of hubs,
> some part of me wonders if the bus is best represented as 'hubs' and
> 'things which attach to hubs', i.e. have root hub as the root of the
> tree, devices and other hubs attached to it, etc.)

That's how it's normally done (normal meaning the Windows world, but
also meaning how the "portable" USBDI spec looks at the world).

Some random thoughts and facts follow:

The whole issue of USB locators is problematic, and hasn't yet
been solved very well by anyone.

The physical locators are geographical -- the device is assigned an
address dynamically.  It probably will be confusing to people if 
a physical location is part of the way people actually refer to
devices; ports are not normally marked in any way.  

Devices can have, but are not required to have, a unique serial number.
Similarly, they can have, but are not required to have, string 
descriptors that identify the device.  The only guarantee from the
spec is that the manufacturer id and device id be set; these are
like the PCI mfg/dev id.  Cheap devices normally don't have
serial numbers.

Microsoft uses the combination of device ID and physical location
as a primary ID for the device; that's the database key that is used to 
store the information about which driver is to be loaded.  This
key is also used to store driver-specific setup information.
This has the undesirable effect that a device's settings may 
change depending on what port the device is plugged into, because 
there are different driver keys.  Of course, if one knows what
one is doing, this is good; but (with modems under Win98) upper
levels of the system end up mapping the two different instances
back to the lowest available COM port, which is awkward sometimes,
and leads to support headaches.

Once the driver is loaded, it registers with a GUID-based database,
exporting IDs for each of the top-edges the driver supports
(for example, "I'm a modem" -- meaning that it supports the appropriate
driver API -- "I'm a HID device"; and so forth).  

Upper layer drivers that are looking for lower-edge things to
control also register with those GUIDs; the API is set up so that
the order of registration is not very important.  So things get
activated as drivers come along.  Teardown is done by the PnP
manager, and is actually rather ugly to deal with as a driver
programmer, because it was an afterthought that was kluged into
the WDM interface.  [If/when NetBSD does Plug and Play or power 
management, it should do so in a way that doesn't require 
each driver to be heavily modified; the WDM model is very
flexible but requires tedious and errorprone bookkeeping on each "method"
of a device driver object.]

Anyhow -- the association to "/dev/foo" is normally
managed by the upper level drivers; though you can do yourself
in your dirver it in NT and WDM, it's deprecated.  In the brave 
new world, the applications browse a database by GUID, and get
"friendly" names from the the database, and you select by clicking
with a mouse......

But I digress.

One key design decision that must be made for things like USB
modems, USB floppy drives, USB xxx is:  what to do about (plug
and play?) assignment of logical names to the physical (internal)
names.  Of course, one can just populate /dev with a zillion
names and similar zillion major/minor ids, but that seems a bit
procrustean.  In addition, it's not clear whether IEEE-1394 (which
is the same thing, but adds networking, peer-to-peer, and
400MB/sec to the mix) can be made to fit into that model.

--Terry