Re: config_activate()/config_deactivate() ?

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Mon, 6 Apr 2009, David Young wrote:

> Calling config_deactivate() seems like too little, too late: card
> ejection is not synchronous with interrupts, ioctl()s, et cetera, so the
> kernel may have already begun a sequence of bus_space(9) reads/writes
> when config_deactivate() is called.  Some systems will trap the bad
> accesses.

Oh dear.  I hope you're not trying to implement true asynchronous hotplug 
this way because it won't work they way you think it will.

Most hotplug frameworks, like PCI hotplug, have the user signal the desire 
to remove a device to the OS.  The OS then deconfigures the device and 
lights an LED, then the user removes the card.  Signaling the OS lets the 
OS detach the driver.  The driver should determine if it's busy and if so 
refuse to detach, which will prevent the OS from lighting the LED.  A 
properly written driver will set a flag when it gets the detach request 
which will cause it to refuse any new I/O operations and let any pending 
requests drain.

If you don't use the handshake sequence you can extract a device in the 
middle of a DMA or PIO cycle.  If that's the case the machine will trap, 
but some machines such as some Intel boxes the OS will not intercept the 
trap, instead the machine will simply reset.

What you seem to be proposing, which is to mark a bus_space handle as 
invalid, would be an asynchronous event.  If the processor has proceeded 
beyond the code that does the handle validation it may still issue the PIO 
operation to what is a currently invalid bus_space.

The only way you can implement this sort of thing is to use the same sort 
of mechanism used for copyin()/copyout() or *peek()/*poke() routines:
have the bus_space*() accessors set a flag around each load/stor/inb/outb 
instruction indicating it's an access to a potentially invalid memory 
location, and then if the operation traps, have the trap handlers use that 
flag to skip that instruction and return to the trapping code.  This will, 
of courese, require some thought and rework of the trap handlers, 
especially since you want devices that are not hot-pluggable to cause a 
panic.

Eduardo