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

Chris,

I get the feeling you totally ignored what i wrote.

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

My take on this is that static, config-and-rebuild-the-kernel-
and-reboot changes just don't cut it *for me* and in other environments.


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

no, but it *IS* stupid to provide that as the only mechanism whereby
USB busses *can* be configured and whereby locators can be specified.

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

Almost.  NetBSD is supposed to "do things right".  USB Bus-topology
works for you but it doesn't work for everyone, and it *DOES* break a
more flexible, more general solution (which, of course, should also be
able to "wire down" attachments in the way you'd like.)


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

Exactly.  It's not your place to insist on what people can do with
their hardware systems and what they consider "properly nailed down".
Forcing people to use bogus locators -- like USB topologies, in those
environments where that *IS* bogus -- is wrong.

We've had similar disagreements before; I dont know why but you
consistently refuse to accept that doing things the way *you* want
prohibits other, more flexible designes, where any necessary "wiring
down" is done at a higher layer.

>(Indeed, right now it's the only piece we can provide.

Fix the config machinery.

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

Fine. But by the same token, we MUST NOT prohibit people who want to
lock things down based on specific device identifiers, or whatever.