On Fri, Jun 16, 2000 at 11:12:59AM +0100, David Woodhouse wrote:
>
> That's sort of what I meant by the question - how easy would it be to fix
> up CardBus, which is the only current code I know of that's likely to do
> this? Actually making the declaration and sticking the semaphore in is the
> easy part :)
I think it would be hard and I'd suggest not attempting it as a
pre-2.4 project. It is still a race so I understand the motivation,
but it is a race that requires deliberate user abuse to trigger (i.e.,
jerking a card in and out with just the right timing). The race does
not happen if you "follow the rules" and do an orderly device shutdown
before ejecting the card.
You'd need to rewrite a lot of PCMCIA code to not be interrupt driven.
We get a "card eject" interrupt and pass it to the driver as quickly
as possible. I am not convinced that it is even a good idea to change
that: I think it is sensible to tell a driver that its hardware no
longer exists as quickly as possible. Of course, cleanup stuff like
tearing down PCI bus structures does not need to happen immediately,
and could be done later in a thread context. For 16-bit PCMCIA
drivers, the card-eject event normally is just used to mark a device
as dead, and all the cleanup stuff happens in other callbacks. For
the CardBus hot plug API, there aren't hooks for that.
Actually... this makes me think of something that might be more
generally useful. Right now we have timers that run in interrupt
context. Might it be useful to also have a kernel thread that runs
timer-like stuff, with a timer-like API, but since it is a thread, can
sleep? So we could say "run this in thread context as soon after time
X as possible" or "run this in thread context as soon as possible".
-- Dave
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:12 EST