Date: Wed, 23 Sep 2009 10:21:59 -0700 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.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: <4ABA5937.9000406@elischer.org> In-Reply-To: <200909231209.08346.jhb@freebsd.org> References: <200909231554.n8NFsYwT078965@fire.js.berklix.net> <200909231209.08346.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > The umtx stuff used by libthr assumes it can do a cmpxchg in > userland for example. One idea kicked around many years ago was catching the > illegal instruction faults for userland and emulating cmpxchg, but that would > be a good bit of work. FreeBSD now also makes liberal use of 'xadd' for > reference counts (see refcount_*()) so you would need to support that on a > 386 as well. There may be other places that I'm not aware of that have > similar assumptions. FWIW, I would probably not be in favor of putting any > patches into the tree if you do manage to get it all working. I suspect the > userbase of FreeBSD/80386 is even smaller than FreeBSD/alpha or > FreeBSD/sparc64 and 80386 support would add a lot of ugly #ifdef's for > miniscule gain. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ABA5937.9000406>