bill,

We seem to be talking at cross-purposes.

You seem to be considering only the case of PCI LKMs, and seem (to me)
to be suggesting duplicating lots of the existing PCI machinery to
handle that case.  Whereas I'm thinking of how we could support LKMs
for arbitrary direct-config buses, with PCI as a specific example.


What I'm trying to say is that *if* PCI drivers reserved bus resources
which correspond to the `device' rahter than PCI resources used by the
device -- say, slotnumber for the sake of argument--, and if the
PCI-bus autoconfig code reserved "slot number" for each device as it
was matched and attached, then we could re-configure a new PCI bus
*just* by re-starting autoconfiguration from the node for the
PCI-bus parent.



>I am suggesting we add a new structure which essentially would be the pci
>match arguements. Keeping track of which devices are "new" and "old" is
>easy - if when we look, the match arguements are what we remember, it is
>"old".

I am suggesting that if we need to go scan everything *anyway*, why
*bother* keeping the locators/match arguments around? Just keep track
of which devices have already been grabbed by drivers, using an extent
map for some unique attribute (for PCI, header block address, maybe?).


For hotswap, i don't (yet) buy that the inference "new" = "old" is
acutally valid -- consider swapping out a suspect card for another
instance of the same card. I think in that case, hotswap really
requires explicit notification of insertion/removal events.

And yes, at least for the hardware we once built here, changing the
memory-address/io-addres registers while the device is active can do
*really* horrible things. :)


>my concern is that pci match routines don't allocate anything. The BIOS
>will have done that for us. All the match routines do is look at the info
>I list above. So each time we scan a slot, we will match it.

You are right, i was thinking of ISA resources.  for my idea to work,
the match and attach routines for direct-map devices would have to
allocate (and release, for match) some resource which uniquely
identifies the device instance, just as we do now for ISA.

I still think that is a cleaner and more generalizable approach,
but i'm willing to be convinced otheerwise.

--Jonathan