Date: Wed, 23 Sep 2009 14:36:28 -0400 From: John Baldwin <jhb@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: Rui Paulo <rpaulo@gmail.com>, Alexey Shuvaev <shuvaev@physik.uni-wuerzburg.de>, "Julian H. Stacey" <jhs@berklix.com>, hackers@freebsd.org, Nate Eldredge <nate@thatsmathematics.com> Subject: Re: genuine cpu I386_CPU kernel support Message-ID: <200909231436.29466.jhb@freebsd.org> In-Reply-To: <4ABA5937.9000406@elischer.org> References: <200909231554.n8NFsYwT078965@fire.js.berklix.net> <200909231209.08346.jhb@freebsd.org> <4ABA5937.9000406@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote: > John Baldwin wrote: > > On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote: > >> Rui Paulo wrote: > >>> On 22 Sep 2009, at 19:03, Nate Eldredge wrote: > >>> > >>>> On Tue, 22 Sep 2009, John Baldwin wrote: > >>>> > >>>>> My comment is to just use 4.x (seriously). A true 386 is going to > >>>>> be quite > >>>>> slow and the overhead of many things added that work well on newer > >>>>> processors > >>>>> is going to be very painful on a 386 (probably on a 486 as well). > >>>>> 4.x runs > >>>>> fine on a 386 and should support all the hardware you can stick > >>>>> into a > >>>>> machine with an 80386 CPU. > >>>> Unless, of course, you plan to put it on a network. I doubt that > >>>> 4.x is up to date with respect to security patches. > >>> I don't know if they were all applied on 4.x, but I think at least the > >>> older ones are. > >> 4.11 fell out of security support some while back, but > >> http://www.freebsd.org/security/index.html > >> only lists what's still in, not what fell out when. > >> > >> Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of > >> BSD to 386. Would be nice if we could still keep that first platform > >> walking, even if speed can't be called running ;-) > >> > >> Maybe I'll get time to chase down all that came before > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=137784 > > > > Other things added since then assume at least a 486. Not having cmpxchg is a > > bit of a killer. > > I think a 386 can assume non-SMP in which case that can be simulated > just fine :-) > it also simplifies a lot of the other breakages.. > > #if (CPU == 80386) && defined(SMP) > #error "can't have smp on a 386" > #endif No, it actually does not. The in-kernel version of cmpset for 386 was to disable interrupts while doing a cmp and jmp around a mov (even 386's have preemption, so you do have to disable interrupts). You can't do that in userland (cli is a privileged instruction), which probably mandates doing a cmpxchg emulator in the kernel for userland code. That and disabling interrupts is actually far less efficient than spl() for a UP 80386 machine. I suspect newer kernels will run slower on an 80386 than 4.x. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909231436.29466.jhb>