> Trying to make the kernel automagically "get it right" , using only
> bus-specific locators, when you can pull out, change, and reorder
> devices "on the fly", seems like a lose to me.

This indeed may be impossible.  That's not as much of a concern as
things like "machine powers on, but a device somehow doesn't make it,"
or "person plugs in and unplugs a strand of devices, and one of them
fries," or "pet chewed through/dislodged a wire and person rebooted
the box."

In order to make any hard-wired scheme work right, a person trying to
do it is going to have to make a commitment (to themselves) to not
randomly reorder devices, or whatever.  You can always create some
scenario that will screw up configuration, and we do _not_ have to
cope with that.

However, as OS providers we have to give people the flexibility in the
configuration framework so they can nail down certain things, and
expect certain behaviour even in the face of unexpected
additions/deletions/failures.

For instance: "hard wire root disk to sd0 and scratch disk to sd1, and
data disk to sd2 so that if I forget to power on scratch disk i won't
scratch my data disk."  Similarly, hardwire bus configuration so that
if nothing bad happens, my 'normal' audio speakers (which I've
configured in a certain way) will always show up at units 0 and 1 so
that if one of them fails to come up, I don't blow the windows out of
my office by pumping audio to something More Powerful.  8-)


We can't provide all the solutions to the configuration problems.
It's impossible to do so, and impossible to even attempt to do so.
In general, we should make the default configurations of systems as
flexible as they can possibly be.

However, we should provide the capability for people to hard-wire
configuration information using as much information as we can bring to
bear and that is necessary to hard-wire device configurations.  That
includes:

	* bus topology.

	* any bus/device/function/port/whatever numbering they might
	  possibly be aware of via "normal" means and that is
	  deterministic.

	* device identification strings, be they device/manufacturer
	  strings, serial numbers, or whatever.

Currently, we have no way to provide/use the latter, but we do have
ways to provide the former where two there is meaningful data to
provide.

PCI primary bus bridges and PCI-PCI bridges get you topology, as
should USB hubs/busses.

PCMCIA ports, EISA, PCI and TC slots, etc., get you deterministic
numbering (though not something which necessarily obviously maps
directly to hardware).

They key here is that you can boot a system in one configuration, copy
information about it (printed in the boot messages) down, and use the
information to hard-wire a config file.  In some cases, for certain
types of topology, you can actually use some knowledge of the topology
of the system to try and sort things out before hand.


In a nutshell, it's important that autoconfiguration (including or
excluding dynamic addition and deletion of devices) provide both the
flexibility to support arbitrary hardware configurations generically,
and allow users to tailor their configuration files to nail down
specifically the hardware that they have, at certain locations, so
that perturbations of their system will have predictable effects.  In
some cases, it's just not possible with the current 'technology' that
we have.  In this case, there is at least something which can be done
(exposing some topology).


cgd