Date: Sun, 18 Mar 2001 18:39:44 +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.0103181805070.26885-100000@besplex.bde.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 Sat, 17 Mar 2001, Matthew Jacob wrote: > On Sun, 18 Mar 2001, Bruce Evans wrote: > > > On Sat, 17 Mar 2001, Matthew Jacob wrote: > > >... > > > .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. It's MD, so the MI functions shouldn't be burdened with semantics to make them usable for it. If you start the PROM entry as an MI function, better reach the MD parts early so you can use them. This stuff is too MD to really share much 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? I think there is no problem with guaranteeing nesting in drivers if drivers follow the rules, and this must be guaranteed so that drivers don't have to worry about. The public interfaces that we are discussing are mainly for drivers. If there is a problem with interrupt nesting, then it is in the implementation of mutexes and/or ithread scheduling. Whatever is used there need not be the same as the public interface. [Hard to parse paragraph repeated] > > 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.0103181805070.26885-100000>