Date: Sat, 24 Mar 2001 20:37:35 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II Message-ID: <Pine.BSF.4.21.0103242025380.27033-100000@besplex.bde.org> In-Reply-To: <XFMail.010323211637.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Mar 2001, John Baldwin wrote: > On 24-Mar-01 John Baldwin wrote: > >> This was really a renaming of the x86-specific interfaces read_eflags() > >> and write_eflags(). I object to the x86 code being changed to use the > >> new names. The x86 code that disables interrupts mostly wants precisely > >> the MD interfaces, not the MI abstraction of them. It just happens that > >> the MI versions are binary-identical with the MD versions. > > > > Ok, I could go with that. (/me deletes half of his patch.) > > Actually, I thought about this some more. Most of the places that do this (for > example, before setting cr0 or something else critical) don't really care about > any of the flags values, they are just keeping from being preempted, so I think > that using critical_* in those places is more appropriate. If something needs > to read eflags and act on it, then one would use read_eflags(). MD code still > calls MI functions in other places. But these places mostly need to know precisely what critical_* prevents. I'm not sure that the semantics of critical_* can or should be defined precisely enough for MD code to rely on. Here is one way that critical_enter() might be different from `read_eflags(); disable_intr()' on i386's: that latter certainly disables interrupts, but the former might only disable them virtually (let them occur, but don't let them proceed far, except possibly if they are fastintrs). Only very critical, very MD code should care about the difference between interrupts being disabled and interrupts apparently being disabled. The cr0-setting code is barely critical enough to care (but disabling interrupts early in the boot should be moot; it's simplest to disable interrupts globally and depend on this). BTW, the cr0-setting code seems to be entirely SMP-unaware; it seems to be only called for 1 CPUs (but this is OK since it is only used for old CPUs that don't support SMP). 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.0103242025380.27033-100000>