Messages in this thread |  | | Date | Mon, 7 Jun 1999 04:04:58 +0200 (CEST) | | From | Chipzz <> | | Subject | Re: RFC: Devices, buses and hotplug |
| |
On Sun, 6 Jun 1999, David Hinds wrote:
> From: David Hinds <dhinds@zen.stanford.edu> > Subject: Re: RFC: Devices, buses and hotplug > > On Sun, Jun 06, 1999 at 07:00:52PM +0100, Alan Cox wrote: > > > > > (4) The bus-dependent code receives an unplug notification and sends > > > it to the driver. The driver releases the device, bus-dependent > > > code removes it and deallocates all of its resources. Done. > > > > What if the driver says "Im in the middle of something" or "but there > > is an fs mounted". > > > > Just to remind you its -not- trivial 8) > > 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
For example we could make a buffer to store all "unsent" data, and display a message to the user that data needs to be "sent" to the device, and if he could -PLEASE- replug it, and if it gets replugged, send all remaining data.
I think this is the same as the FDD case: one can push the eject button at any time, and if data needs to be written, tough luck. (not true on the MAC IIRC, but that's not the issue here)
Essentially, I don't think it's really a linux-specific problem, since such situations can happen on any OS. But it would be nice to have a good way of dealing with it though, eg (maybe this is a stupid example) the buffer thing I described above. IMVHO, it's not only a PCMCIA problem, confer the FDD case mentionned a- bove.
> "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. > > -- Dave Hinds
Just my 0.02 Euro anyway.
Greetings,
Chipzz AKA Jan Van Buggenhout
-------------------------------------------------------------------------- UNIX isn't dead - It just smells funny Xp@Ace.ULYSSIS.Student.KULeuven.Ac.Be --------------------------------------------------------------------------
- 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/
|  |