Date: Sat, 17 Mar 2001 22:35:12 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: 'final' man pages Message-ID: <Pine.BSF.4.21.0103172230500.65844-100000@beppo.feral.com> In-Reply-To: <Pine.BSF.4.21.0103181525120.25981-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Mar 2001, Bruce Evans wrote: > 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. *chortle* Heads I win, Tails you lose (I wrote that function and man page for Solaris 2.0). > > > .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! > > >... > > .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... I'm not following this. Entry to the PROM is certainly an MD function. It may start as an MI function, but has to go through MD code. > > > .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. 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? > 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.0103172230500.65844-100000>