From owner-freebsd-arch Sat Mar 17 22:35:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B555137B71A; Sat, 17 Mar 2001 22:35:21 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA29192; Sat, 17 Mar 2001 22:35:16 -0800 Date: Sat, 17 Mar 2001 22:35:12 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > .Ft void > > .Fn restore_intr "intrmask_t" > > Should be: > > .Fd #include > .Fd #include > ... > > ( 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