wrstuden@zembu.com said:
> I don't think we were talking about two contradicting configuration
> frameworks.

Well, having devices look for the best matching driver or having drivers
look for devices which could be handled are quite differing approaches
to the "find bast match between x and y" problem.
"contradicting" might be a harsh word, but it's not exactly the same
philosophy either...

> The problem here is that we'd need to also extend the config system to be
> able to inject more locators once booted (and also be able to delete
> them).

Since it is part of my job to deal with homegrown and experimental hardware,
I've been thinking about loadable device drivers for quite some time.
What I had running in 1.3 times (actually, I'm still running 1.3 on a number
of systems for that reason) was to have a (linked) list of configuration
tables as generated by config(8), each consisting of the cfdata[] and cfroots[]
arrays which are global and singular originally. LKMs could append their
own lists, and the autoconfiguration functions considered the entries of all
present lists instead of just the primary one. I had even a hacked version of
config(8) for that purpose, so I could set up a config file snippet with
all the attachment specifications and locators and options, and the resulting
LKM did behave that way. (It was about VME devices partly, and for VME
the locators are essential - worse than ISA...) There is a number of issues
which are not so easy to solve, especially the connection points between
these configuration tables, and some reference counting problems. I didn't
have time do deal with all of this; what I did was just enough to work in
an environment where the operator knows what he is doing.
What I want to say: I know it is doable.

> Is architectural purity worth pciide drivers not working?

As I wrote in another mail, there is at least one other way: the bus/device/
function numbers of the ISA bridge are probably well-known in this case because
the IDE interface in within the same chipset. One could perhaps also
use some parent-child-links within the "struct device", or even use
a special pciide attachment to this special pcib device.
I don't by any "there is no other way" argument, and even then there is
no need to create a new pseudo-generic public interface.

best regards
Matthias