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

The issues around configuration locators are independent of whether
the kernel is static or there exists dynamic driver configuration
or even configuration loading.

In all cases, you have to specify locators so you know what to attach
where.  In all cases, the kernel (the place where device drivers live)
has to be able to figure out what to attach where.  The configurations
and drivers loaded into the kernel may be loaded dynamically, but that
doesn't change the issue that the kernel still has to know what's
going on.


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

What other mechanisms should be provided in addition to the ones that
I've specified?

I've already suggested topology and any string-based information which
might be useful.  However, I've pointed out that until the
configuration code is fixed (and i've said it should be, but that it's
non-trivial to do so) the _only_ thing that is possible is topology.

The initial thing that got me into this argument was that people
seemed inclined to _refuse_ to allow people to use topology to
wire down devices, which is bogus.


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

Again:

What more than i've said should be specified should be specified?

What more than i've said should be specified _can_ be specified?



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

I'm not forcing them to use topology for anything.  I'm "forcing" the
people who would implement the bus infrastructure to _allow_ them to
use the topology.


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

Again, what would you suggest in addition to what i've already said
should be used?


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

"No, you fix it, since you're so keen on it."  It needs to be fixed,
who fixes it is really an issue of who puts in the time.

But even when it is fixed, topology is still a valid way to determine
what devices are configured where.


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

And i've _said_ that they should (in the long run) be able to do that.

Nowhere have I said that they should not be able to do that.  I've
said that the existing config code doesn't support it, and SHOULD BE
FIXED.

However, even if it is fixed to allow things like string locators,
topology is still a valid identification mechanism for some uses.




cgd