From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 23 17:21:57 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64AE1065676 for ; Wed, 23 Sep 2009 17:21:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 8895B8FC25 for ; Wed, 23 Sep 2009 17:21:56 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 33814B98A2; Wed, 23 Sep 2009 10:21:57 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 474D82D601B; Wed, 23 Sep 2009 10:21:56 -0700 (PDT) Message-ID: <4ABA5937.9000406@elischer.org> Date: Wed, 23 Sep 2009 10:21:59 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Baldwin References: <200909231554.n8NFsYwT078965@fire.js.berklix.net> <200909231209.08346.jhb@freebsd.org> In-Reply-To: <200909231209.08346.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , Alexey Shuvaev , "Julian H. Stacey" , hackers@freebsd.org, Nate Eldredge Subject: Re: genuine cpu I386_CPU kernel support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:21:57 -0000 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. >