wrstuden@zembu.com said:
> The thing is that our current autoconfiguration philosophy implicitly
> assumes that we scan the bus once

One _can_ scan the bus later again if the bus support code provides a hook
for this. scsi has this, and for pci it would be easy to add.
There should be some ressource management which keeps track of child
devices so that a driver working on a device is not stomped on.

> That's not true for LKMs, so it seems to me to be harsh to say that
> LKMs are broken since they don't use the config model which doesn't
> work for them. :-) 

Why not? The LKM init code can have some pci_rescan() or so code scan
the bus(es), which would work more or less like the initial autoconfiguration
and call the xxxmatch() finction(s) of the driver(s) within the LKM.
This needs some thoughts and work, but is much better than having two
contradicting configuration frameworks within one system.

> I think the best thing would be to add the function(s) we've been talking
> about, and to add info in the pci bus code so that we remember what we
> find.

The least thing I'd like to have is some control which physical devices the
LKM driver should care about, in case there is more than one present.
Just like the initial autoconfiguration provides through its config(8)
generated locators.

As I said, I'm afraid if we start to provide such a pci_scan function,
it will be used, and that would be catastrophic from the architectural
cleanlyness POV imho.

best regards
Matthias