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

John Baldwin jhb at FreeBSD.org
Wed Oct 20 12:11:00 PDT 2004


On Tuesday 19 October 2004 05:47 pm, Scott Long wrote:
> John Baldwin wrote:
> > 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.
>
> I agree that 80386 support should not be removed from RELENG_5, but I
> don't see anything wrong with optmizing the common case and adding an
> extra 80386-specific hurdle to 5.x.

It would be nice to have some actual real-world benchmarks that show that this 
change actually buys something.  Recompiling a kernel isn't too high of a 
barrier to entry, but recompiling userland is a bit much.  Many moons ago we 
decided to not remove 80386 support from 5.x, and since we've already 
branched RELENG_5 I think we are pretty much stuck with that now.  6.0 won't 
be that long in coming and we can kill it for good there.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the cvs-src mailing list