Date: Sun, 18 Mar 2001 16:22:37 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Jacob <mjacob@feral.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: 'final' man pages Message-ID: <Pine.BSF.4.21.0103181525120.25981-100000@besplex.bde.org> In-Reply-To: <Pine.LNX.4.21.0103171241240.2328-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Mar 2001, Matthew Jacob wrote:
> Incorporating Terry's comments, here's my last cut for the three
> functions... I think it's better if they're separate man pages.
>
> Can we all move to closure on this? The only other issue I can think of here
> is the semantics of an enable_intr() in between a disable_intr/restore_intr
> call.
No. I don't agree that these functions have the correct semantics. The
Solaris ddi functions that you quoted are much better.
> .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.)
>...
> .Fn disable_intr "void"
> .Sh DESCRIPTION
>...
> The purpose of this function is inhibit interrupts from being dispatched
> to the calling CPU. It may be used to ensure the timely execution of short
> segments of hardware dependent critical code. It may also be used
> to ensure the preservation of certain platform specific machine state
> when calls outside of the kernel (e.g., to supporting PROM code) are made.
I think MD functions should be used for preserving MD state. The MI
functions may do things that are irrelevant or just wrong for entering
PROMs...
> .Sh RETURN VALUES
> Returns a interrupt mask value that is to be later passed
state (masks and levels have very different semantics
which should probably be opaque here; better
rename intrmask_t too)
> .Xr restore_intr 9 .
It's not even clear that interrupt states can be restored in a nested
way. 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. 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.
Bruce
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?Pine.BSF.4.21.0103181525120.25981-100000>