James Carlson wrote:
> David Kahn writes:
>
>
>
>> the guarantee is that open, close, attach, detach and other driver
>> entry points will not be active or called when the framework calls
>> quiesce(9e). That still leaves the question of interrupt handlers,
>> timers, callbacks, etc that could be called when the driver is
>> in quiesce(9e) or might be active when the quiesce(9e) is called.
>>
>
> That means the system can never call quiesce(9E) on (at least) serial
> ports. That doesn't sound like a good answer to me.
>
Why? It seems (to me at least), that if there is something that needs a
timeout, the quiesce routine should be able to discover that a timeout
was pending, and poll for completion on its own.
Maybe I'm just not understanding your concern here.
>> It seems like what you want to do is stop interrupt dispatch,
>> stop callback threads, timer callbacks, soft ints, etc, and then
>> just call into the driver to tell it to stop whatever it might be
>>
>
> I don't see how that's possible. There's nothing in the system that
> knows about existing timeout(9F) callout records on a per-driver
> basis, so there's no way to stop them before entry.
>
Not individually, but *all* interrupts would be stopped. The system
should be running with all interrupts on the CPU disabled.
-- Garrett
