Date: Sun, 18 Mar 2001 00:12:05 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Jacob <mjacob@feral.com> Cc: arch@FreeBSD.org, Bruce Evans <bde@zeta.org.au> Subject: Re: 'final' man pages Message-ID: <XFMail.010318001205.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0103172230500.65844-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Mar-01 Matthew Jacob wrote:
>> > .Sh SYNOPSIS
>> > .Fd #include <machine/cpufunc.h>
>> > .Ft void
>> > .Fn restore_intr "intrmask_t"
>>
>> Should be:
>>
>> .Fd #include <sys/types.h>
>> .Fd #include <sys/systm.h>
>> ...
>>
>> (<machine/cpufunc.h> is an implementation detail. It should never be
>> included directly.)
>
> Urmm.. Huh. John told me to do it! It's his fault!
I'll defer to Bruce on this one, he is more of an expert in header foo.
>> It's not even clear that interrupt states can be restored in a nested
>> way.
>
> Yes.
>
> Bruce- the following paragrahph is really hard to parse. I *think* you're
> saying that we cannot guarantee nesting. That's a fair addition. Anything
> else?
Hmm, as long as you pair state changes with restores you can handle nesting in
the same way that spl's did, i.e.:
x = intr_disable()
...
y = intr_disable()
....
restore_intr(y)
....
restore_intr(x)
will DTRT and not enable interrupts until after the second restore_intr().
You do have to pair them up much like lock acquire/releases.
>> Some cases need to be handled like ithread priorities: a handler
>> for a high priority interrupt may have to yield to the handler for a
>> lower priority interrupt to contest a lock. This requires some non-nested
>> handling of interrupt states. I discussed this with John (jhb). He was
>> more pessimistic about it than me.
If a machine supports an external mechanism for disabling interrupts such as a
PIC mask, then we can simply disable individual interrupts that way until the
ithread associated with an interrupt source completes. Note that we only
really need to do this for level-triggered interrupts. If we don't have this
available and are forced to (ab)use the CPU interrupt level to mask interrupts,
then we instead disable all other device interrupts on this CPU when an
interrupt comes in until the associated ithread finishes.
>> I think things currently work on
>> i386's because the interrupt state isn't all actually returned by
>> save_intr() or restored by restore_intr(). Most of the state is in the
>> ICU or APIC, and we depend on this because the state is a mask and not
>> a level. Priority propagation is more complicated because low priority
>> interrupts aren't masked while high priority ones are being handled; we
>> let them occur and then mask them. If we didn't have the global state
>> in the ICU/APIC, then we would have to adjust the saved state in various
>> stack frames, but this is too hard. OTOH, on alphas the interrupt state
>> is controlled by a level and not a mask, so lower priority interrupts
>> can't occur and I think nested handling of interrupt states works right
>> provided ithread priorities work right. Only the case where the interrupt
>> state is a mask and is all returned by save_intr() is broken, and we don't
>> support any machines that require that.
Actually, all device I/O interrupts on the alpha are at the same level, so they
aren't split across multiple levels. Also, we lower the IPL back to 0 before
running an ithread, so that only the actual interrupt stack that schedules an
ithread to run runs at a raised IPL. As they are currently implemented,
*_intr() only allow one to guarantee that the current thread on the current CPU
will not be preempted. It doesn't set a level of interrupts that are allowed
like spl's. That is managed separately by the interrupt code.
>> Bruce
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010318001205.jhb>