Date: Wed, 20 Oct 2004 00:09:04 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: John Baldwin <jhb@freebsd.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/libc/i386/net htonl.S ntohl.S Message-ID: <20041019220904.GA98840@falcon.midgard.homeip.net> In-Reply-To: <200410191748.51589.jhb@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> writes: > > : On Tuesday 19 October 2004 10:43 am, you wrote: > > : > In message: <20041019073145.GA29746@thingy.tbd.co.nz> > > : > > > : > Andrew Thompson <andy@fud.org.nz> 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.) -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041019220904.GA98840>