From owner-freebsd-arch Sat Mar 17 21:23: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AE7F337B718; Sat, 17 Mar 2001 21:22:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA31596; Sun, 18 Mar 2001 16:22:55 +1100 Date: Sun, 18 Mar 2001 16:22:37 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matthew Jacob 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 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 > .Ft void > .Fn restore_intr "intrmask_t" Should be: .Fd #include .Fd #include ... ( 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