Date: Sun, 18 Mar 2001 00:12:08 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.org, Matthew Jacob <mjacob@feral.com> Subject: Re: 'final' man pages Message-ID: <XFMail.010318001208.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0103181805070.26885-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Mar-01 Bruce Evans wrote: > On Sat, 17 Mar 2001, Matthew Jacob wrote: >> > > .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. Actually, while *_intr() do prevent preemption, that is all they do. They do not serve to protect data, so most drivers should be using spin mutexes in these cases instead as spin mutexes both prevent preemption and protect data. If the driver just needs to prevent preemption, it can use *_intr(). If the driver just needs to protect data, it can use a sleep mutex. Basically, *_intr() should probably be used very little in a driver, except perhaps if they are used while holding a sleep lock that protects the data used in the critical section. Note, however, that *_intr() can not be used to protect data and thus are probably not suitable for most applications. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010318001208.jhb>