Date: Wed, 20 Oct 2004 04:11:03 +0300 From: Maxim Sobolev <sobomax@portaone.com> To: Julian Elischer <julian@elischer.org> Cc: fjoe@samodelkin.net Subject: Re: cvs commit: src/lib/libc/i386/net htonl.S ntohl.S Message-ID: <4175BB27.2010406@portaone.com> In-Reply-To: <4175B591.4090407@elischer.org> References: <20041019071102.GA49717@FreeBSD.org> <20041019072349.GA28133@samodelkin.net> <20041019073145.GA29746@thingy.tbd.co.nz> <20041019.084324.106215221.imp@bsdimp.com> <4175B0CD.1050204@portaone.com> <4175B591.4090407@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > > Maxim Sobolev wrote: > >> M. Warner Losh wrote: >> >>> In message: <20041019073145.GA29746@thingy.tbd.co.nz> >>> Andrew Thompson <andy@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 > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4175BB27.2010406>