Re: RFC: Devices, buses and hotplug

Chipzz (xp@Ace.ULYSSIS.Student.KULeuven.Ac.Be)
Mon, 7 Jun 1999 04:04:58 +0200 (CEST)


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/