> > On the other hand, it should be possible for a user who cares to nail
> > down the relevant details as best they can, so that if they happen to
> > add a new device at a 'bad' place, or if one of their devices powers
> > on non-responsive, something "close to right" continues to happen.
> > 
> > USB gives at least location as a mechanism for doing that, although
> > it's apparently not a particularly great mechanism.
> Point taken.  I'll try and get physical location as a locator
> for USB.  A physical location will then be a sequence of 1-5
> (there is a limit of hub depth to 5) port numbers that tells
> you how to navigate from the root to the device.

Why is this better than something based on autoconfiguration 'busses,'
etc.?

If you do it based on busses, and decide to move things around, it's
easy to do.  You also have to represent only one layer (wire? 8-) at a
time, which seems right.


> This brings up the point of locators with multiple values again.
> I posted a suggestion on how to do it long ago, but got very little
> feedback.  And yes, string valued locators would also be handy.

Uh, actually, I seem to recall that you got enough feedback to tell
you how to implement it in config, and that you weren't willing to do
so at the time...


> Another problem, that Terry Moore mentioned, is how to handle
> the gazillion of device names that the current scheme would use
> in /dev.  Should we invent a special file system (mounted at
> e.g. /dev/usb/) in which devices appear and disappear as physical
> devices come and go?

How many do you really think you need?

I mean, why not as a default provide, say 10 hub device nodes, 10
audio, etc.  A special file system isn't necessary, but a subdirectory
might be nice to keep the clutter out of /dev.

It's a bunch of devices, but look at the number that disks use...


BTW, somebody said something about FreeBSD implementing a "devfs":
yes, and they've been in the process of implementing it for years, and
to the best of my knowledge never came up with solutions for the hard
aspects of the problem (like how to store persistent changes to the
directory, if it's actually going to be used as /dev).



cgd