In message <Pine.NEB.4.21.0105021345520.343-100000@candlekeep.home-net.internet
connect.net>Bill Studenmund writes
>On 2 May 2001 eeh@netbsd.org wrote:
[..]

>> 
>> "already configured" devices can be removed or replaced, so they need
>> to be re-probed, at least enough to determine they are still the same
>> as last time.
>
>Exactly.

Nope,  at least not for hotswap.


>[snip]


>> All bus drivers (that support hotplug of any sort) need a method
>> of determining what devices are attached to them, and that requires
>> a reprobe.  If the bus hardware can inform the driver that the state
>> of a specific slot has changed, then the reprobe can be limited to that
>> slot.  Otherwise the entire bus needs to be re-probed.
>> 
>> The simplest way to handle re-probing the bus is to keep the original
>> locator information around.  

No, the *really* simplest thing is to just do a reprobe :).

We just have to make the autoconfiguration system is smart enough to
avoid re-probing on "slots" which are already "match"ed (and not yet detached).


>> the installed driver should be o.k.  That information can be kept in
>> many forms, but the easiest would be as properties attached to the device
>> nodes.
>
>See my other note for a different way to handle this. Essentially the same
>thing...

In the non-hotswap case, this is just a cached copy of what we'd find
by re-doing the config step.  Why bother caching it?  If the slot is
currently matched, skip it.  If it's not, grab the info for the
locators.  That's no worse than running scanpci (is it)?


In the hotswap case, i think we need to know which device has been
swapped in any case-- unless we rely on rescanning fast enough to
detect duplicates.  Just what do hotswap direct buses (PCI)
provide, here?