From owner-cvs-src@FreeBSD.ORG Tue Oct 19 22:09:09 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2040816A4CE for ; Tue, 19 Oct 2004 22:09:08 +0000 (GMT) Received: from av13-2-sn4.m-sp.skanova.net (av13-2-sn4.m-sp.skanova.net [81.228.10.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF4F43D41 for ; Tue, 19 Oct 2004 22:09:07 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av13-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 610E637E45; Wed, 20 Oct 2004 00:09:06 +0200 (CEST) Received: from smtp4-1-sn4.m-sp.skanova.net (smtp4-1-sn4.m-sp.skanova.net [81.228.10.181]) by av13-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 5304037E42 for ; Wed, 20 Oct 2004 00:09:06 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp4-1-sn4.m-sp.skanova.net (Postfix) with SMTP id D9FB437E45 for ; Wed, 20 Oct 2004 00:09:04 +0200 (CEST) Received: (qmail 98852 invoked by uid 1001); 19 Oct 2004 22:09:04 -0000 Date: Wed, 20 Oct 2004 00:09:04 +0200 From: Erik Trulsson To: John Baldwin Message-ID: <20041019220904.GA98840@falcon.midgard.homeip.net> Mail-Followup-To: John Baldwin , "M. Warner Losh" , cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org References: <20041019073145.GA29746@thingy.tbd.co.nz> <200410191541.54269.jhb@FreeBSD.org> <20041019.152902.02300007.imp@bsdimp.com> <200410191748.51589.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410191748.51589.jhb@FreeBSD.org> User-Agent: Mutt/1.5.6i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: "M. Warner Losh" Subject: Re: cvs commit: src/lib/libc/i386/net htonl.S ntohl.S X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 22:09:10 -0000 On Tue, Oct 19, 2004 at 05:48:51PM -0400, John Baldwin wrote: > On Tuesday 19 October 2004 05:29 pm, M. Warner Losh wrote: > > In message: <200410191541.54269.jhb@FreeBSD.org> > > > > John Baldwin writes: > > : On Tuesday 19 October 2004 10:43 am, you wrote: > > : > In message: <20041019073145.GA29746@thingy.tbd.co.nz> > > : > > > : > Andrew Thompson writes: > > : > : > I am afraid that recompiling a kernel on i386 will require several > > : > : > days. > > : > : > > : > : Chicken and the egg. To support i386 it must be recompiled, so you > > : > : would have to do it on another box anyway. > > : > > > : > The only people that will seriously want to use i386 these days are > > : > the folks that build embedded systems. Those you have to build on > > : > some host then deploy to the target system. > > : > > > : > There are some benefits to having i386 in the tree. However, there > > : > are also a number of different places in the tree where things are > > : > sub-optimal because we still have support for i386 in there. The > > : > desire to remove them is to make FreeBSD go faster on more modern > > : > hardware. > > : > > : I think 6.0 is the place to drop 80386, not 5.x. I'm already working on > > : a p4 branch (jhb_no386) to remove 80396 support from HEAD, but I think > > : 5.x should be left as is in this regard. > > > > That was the agreement some months ago. 5.x would have it > > de-emphasized to allow easier optimizations, and 6.0 would actually > > remove it unless there was some really compelling reason not to. So > > far, none of the arguments have come close to getting to compelling, > > let alone really compelling. > > > > The low end of most intel based embedded is the Elan chipset these > > days, and old 386 desktops are rare. Support for i386 negatively > > impacts certain low level routines in a number of ways. But we've > > been through all before when we came to the agreement: > > > > 5.x wouldn't support it out of the box, but the clueful can > > coax 386 support out of the source tree. No one was to do > > anything to break it. If someone accidentally did break it, > > it was the resonsibility of the 386 fans to fix it. This has > > happened at least once that I'm aware of. > > > > 6.x would remove support for i386 entirely, unless some really > > compelling reason was presented that wasn't present in the > > original discussion. > > > > David's commits do nothing to change the above, nor were they intended > > to do so. Nothing in the ensuing discussion has changed it either, so > > we're back to the original agreement. I'm posting it here for clarity. > > David's commits mean that the userland is no longer shared, and do so by > optimizing htonl() and htons() of all things which are hardly critical path > code for some unknown value with no benchmarks that I saw. That major change > is not worth the very trivial (if any) gain I think. 80386 should just be > flat killed in 6.0 and I think 5.x's userland can stay as it is. 5.x needs > optimization work in the kernel, not userland. 4.x has the same "slower" > userland that 5.x does, so I don't think "optimizing" userland hton[ls]() is > going to buy us anything worthwhile, but it does obfuscate the code. Changing libc in that way would also mean that you would not be able to create a statically linked binary on a modern machine and then run it on an 80386 (not without jumping through an inordinate number of hoops anyway.) Dropping 80386 support in 6-CURRENT is one thing and I don't have any real problem with that. Dropping/reducing support for a CPU in -STABLE (which is what 5.x will be as soon as 5.3 is out) is a big POLA violation in my opinion. (And just for the record I disagree with the decisions to drop support for FPU-less systems and to remove 80386 support from the default kernel-configuration, but that was at least done in -CURRENT and not -STABLE.) -- Erik Trulsson ertr1013@student.uu.se