>
>The thing is that our current autoconfiguration philosophy implicitly
>assumes that we scan the bus once, and that all drivers are in the kernel
>at that time. i.e. all the xxxmatch() functions which will ever be called
>are there when we walk the bus.
>
>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. :-)

We (mostly Jason) have made significant changes to the
autoconfiguration mechanism since 4.4bsd and Chris Torek's paper.

At least for direct buses, we *should* be able to re-run `config'
after inserting an LKM and updating the configuration tree.

In a really nice world, we could identify all the parents who had new
children added as a result of an LKM insertion, and rerun
autoconfiguration from those nodes only.  If all the drivers properly
reserve their bus-space regions, that should be workable.
(modulo latency during device probes, tests for `cold', etc).

imho thats a much cleaner approach than having two different
autoconfiguration mechanisms, one for boot-time devices,
and a completely different one for LKMs.


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

[...]

Static schemes like that won't help hotswap insertions, if we ever
want to extend to that. do they work for LKMs for bus-bridge devices,
even?