cvs commit: src/lib/libc/i386/net htonl.S ntohl.S

Erik Trulsson ertr1013 at student.uu.se
Tue Oct 19 15:09:10 PDT 2004


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 at FreeBSD.org>
> >
> >             John Baldwin <jhb at FreeBSD.org> writes:
> > : On Tuesday 19 October 2004 10:43 am, you wrote:
> > : > In message: <20041019073145.GA29746 at thingy.tbd.co.nz>
> > : >
> > : >             Andrew Thompson <andy at 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 at student.uu.se


More information about the cvs-src mailing list