David Kahn writes:
> I'm not sure if that's enough. What if open, close, etc are in
> progress when the framework decides to call quiesce. Is that
> possible? So maybe it has to be worded even stronger such that
Not just possible, but likely. The serial drivers all do this
normally; a blocking open(9E) waiting for carrier is the norm.
It also shouldn't be a problem there. The open(9E) is blocked, but
the hardware is idle. It's harmless to shut it down.
> 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.
> This needs a bit of work, IMO.
Yes. I'm not trying to design it here, but one possible answer to
consider would be:
quiesce(9E) may be called while other threads are active in a
driver's other entry points. However, the framework
guarantees that no new calls to open(9E), close(9E), or the
other entry points will be made during the execution of
quiesce(9E).
> 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.
I suspect that all of that, if it's necessary, must be the driver's
responsibility.
(My understanding of this quiesce proposal is that it would _not_ be
necessary to disable callbacks and the like. All that's necessary is
that DMA and interrupts on the hardware are shut down so that nothing
outside of the CPU itself will be doing work.)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
