> I should describe what PCMCIA does to deal with this. PCMCIA cards
> are generally not lockable, so drivers need to cope with unplug
> notifications whether or not the timing is convenient. Verifying that
> "now is a good time" can only be done if the user requests an unplug
> in advance, which sends an "eject request" event to all listeners. In
> the current design, these listeners include the cardmgr daemon, which
> runs user-space checks to see if an eject is safe, though it would be
> more foolproof for the client drivers to respond directly. If an
> eject happens with no warning, all we can do is notify the client
> drivers and let them clean up as best they can. Thus, the "eject
> request" handler can return failure, but the "eject" handler cannot
> fail.
I think that pre-eject checks belong to the drivers and their
attached sub-drivers only.
We can simply introduce two driver hooks: soft_eject (the bus layer
notifies the driver that the user has requested device unplug; the driver
cleans up and returns whether unplug is possible or not) and hard_eject
(aka `we have just lost the device, don't ask why'; the driver cleans up,
revokes all open filehandles etc.).
When a sub-device is attached to the device being ejected, the same
hook is called for all sub-devices before calling for the master device.
It introduces one minor problem which I'm not sure is worth the effort
needed to eliminate it: if it isn't possible to eject the device, we
still eject all sub-devices even if leaving everything in the original
stale would make a little more sense.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Lisp Users: Due to the holiday, there will be no garbage collection on Monday."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/