> >In the config file as:
> >
> >  usbroot* at pci?
> >   usbhub* at usbroot?
> >   usbhub* at usbhub?
> >   usbdev* at usbhub?
> >
> >And if you need to nail things down more:
> >
> >  usbroot0 at pci?
> >  usbhub0 at usbroot0
> >  usbmonitor0 at usbhub0 port 0
> >  usbhub1 at usbhub0 port 1
> >  usbkeyboard0 at usbhub1 port 0
> >  usbmouse0 at usbhub1 port 1
> >  usbhub2 at usbhub1 port 2
> >  usbaudio0 at usbhub2 port 0
> >  usbaudio1 at usbhub2 port 1
> 
> Bill, these are *not* nailed down.  You can't driven nails into
> sand;).  Maybe if you have the machine in a physically-secure space or
> you can mandate "don't touch the USB", this counts as nailed down.
> But that assumption doesn't hold everywhere.  

Yes those are nailed down, or at least as well as they can be with the
information we can provide.

If there's a audio device at hub2 port 0, it will always be audio0.
Another audio device will never be 0.  If the topology changes in a
way that we can detect (and that we can export to the configurer via
config; right now we can't do strings), the mappings will be broken.

If one of the devices doesn't power on, some other device won't
magically take it's place.

That's as close to 'nailed down' as you can come: if the contents of
the bus stay the same (or detectably the same) the configuration code
will do the right thing, if the contents of the bus are detectably
different because of things being added the configuration code will do
something else (e.g. not configure the additional devices, or
whatever not configure them as the 'nailed down' units of devices),
and if devices are removed or spontaneously die the configuration code
will keep other units from being configured in their places.


> Designing long-lived kernel features around "nailed down" locators
> that aren't in fact "nailed down" is just stupid.  A USB design that
> *requires* these locators be specified (as the above seems to) is
> Right Out.

Topology is one valid locator.  Some device identification strings
would be a nice one for the future, but can't easily be provided now.

Indeed, it'd be nice to say things like:

usbaudio0 at usbhub? port ? serialnum "foobarbaz"

to "nail down" that speaker(?) to that audio device, regardless of
where that speaker is plugged into the USB topology.

However, that's only one valid use.

The use outlined above, i.e. something like:

>  usbaudio0 at usbhub2 port 0
>  usbaudio1 at usbhub2 port 1

is perfectly valid as well; you may say "OK, i've got this hub, i've
got two audio speakers, i'm keeping the topology the same, left is in
port 0 and right is in port 1."


Just because you don't want to use that particular function doesn't
mean that it's stupid.


To look at the SCSI code, some people like:

ahb* at eisa? ...
bha* at eisa? ...
scsibus* at ahb*
scsibus* at bha*

which gets you your disks in probe order.

Some like:

ahb0 at eisa0 ...
bha0 at eisa0 ...
scsibus0 at ahb0
scsibus1 at bha1

sd0 at scsibus0 target 0 lun 0
sd1 at scsibus0 target 1 lun 0
...
sd8 at scsibus1 target 0 lun 0

Still others like:

ahb* at eisa? ...
bha* at eisa? ...
scsibus* at ahb*
scsibus* at bha*

sd0 at scsibus? target 0 lun 0
sd1 at scsibus? target 1 lun 0
sd2 at scsibus? target 2 lun 0
...


All have varying levels of "locked down"edness, and all are equally
valid.  The former are used in generic config files.  The middle set
are used if you want to lock everything down in a specific
configuration.  The latter are used if you've got a fixed set of
hardware, but may want to migrate some disks between your SCSI busses.
(I've used this configuration, I used it for years on sun-lamp...)

You seem to be arguing that because you can't nail things down all the
way to the exact hardware device, or something, that it's not good
enough and therefore shouldn't be implemented.  That'd be like saying
since i could take a disk set to target 1 and replace it with Folgers
Crystals, err... a different disk at target 1, i've not locked down
the configuration.  It's not your place to say what people can do with
their hardware systems, and what they consider properly "nailed down."

The point is, the flexibility, in terms of available information needs
to be there to allow users to lock things down (as best they can or
want to).  For USB, topological information is one vital piece of that
information.  (Indeed, right now it's the only piece we can provide.
However, even in the case where we could provide other information,
it's still necessary, since people may want to "lock" things down
based on topology rather than specific device identifiers.)


cgd