Messages in this thread | | | Date | Mon, 7 Jun 1999 12:55:28 +0200 | From | Martin Mares <> | Subject | Re: RFC: Devices, buses and hotplug |
| |
Hello,
> 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/
| |