cvs commit: src/lib/libc/i386/net htonl.S ntohl.S
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
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
<Insert your favourite quote here.>
ertr1013 at student.uu.se
More information about the cvs-src