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

[Maxim Sobolev]

Julian Elischer wrote:
> 
> 
> 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.)

Neither of those technologies is really necessary in such applications 
to be able to justify an additional 4.x vs. 5.x performance/memory 
consumption penalty which will be quite considerable for 
low-performance, low-memory embedded device, which is my point.

> 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.....

You have 5.x for that.

-Maxim

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