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

[Julian Elischer]

Maxim Sobolev wrote:

> M. Warner Losh 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.
>
>
> Can anyone give at least one valid point why somebody will want to use 
> 6.x on embedded i386? Such hardware is inheretedly limited, so that 
> all good stuff that have been added into FreeBSD during the past few years


> (SMPng, GEOM, KSE, you-name-it) is

SMP is the only one of these for which you are correct..

KSE and geom couldn't care about 486 or 386..
I think 386 machines are not going to be SMP.
I would be happy to see SMP completely incompatible with 386
(I mean you don't need atomic operations at all on a UP system, so
any such instructions can be  ignored in that case.)

doesn't mean we shouldn't rip it out.. just pointing out that in fact 
there is a "middle position"
where we continue to support Uniprocessor 386..

> of no use on that hardware anyway. IMO any reasonable embedded folks 
> would just stick

> with 4.x or even 3.x due to their smaller footprint and better 
> performance on old systems. 


I'd like to see a 4.x with threads :-)
hmm maybe dragonfly.....


>
>
> Let's just rip that old junk off!
>
> -Maxim