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

[John Baldwin]

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.

-- 

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