Garrett D'Amore writes:
> 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.
The problem is indicated above. open(9E) is almost always "active" on
a serial port, because there are threads there snoozing away, waiting
for someone to assert DCD.
> >> 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.
It didn't sound to me like that's what the original project was
proposing, but ok.
--
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
