John Baldwin wrote:
On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote:
Rui Paulo wrote:
On 22 Sep 2009, at 19:03, Nate Eldredge wrote:
On Tue, 22 Sep 2009, John Baldwin wrote:
My comment is to just use 4.x (seriously). A true 386 is going to
be quite
slow and the overhead of many things added that work well on newer
processors
is going to be very painful on a 386 (probably on a 486 as well).
4.x runs
fine on a 386 and should support all the hardware you can stick
into a
machine with an 80386 CPU.
Unless, of course, you plan to put it on a network. I doubt that
4.x is up to date with respect to security patches.
I don't know if they were all applied on 4.x, but I think at least the
older ones are.
4.11 fell out of security support some while back, but
http://www.freebsd.org/security/index.html
only lists what's still in, not what fell out when.
Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of
BSD to 386. Would be nice if we could still keep that first platform
walking, even if speed can't be called running ;-)
Maybe I'll get time to chase down all that came before
http://svn.freebsd.org/viewvc/base?view=revision&revision=137784
Other things added since then assume at least a 486. Not having cmpxchg is a
bit of a killer.
I think a 386 can assume non-SMP in which case that can be simulated
just fine :-)
it also simplifies a lot of the other breakages..
#if (CPU == 80386) && defined(SMP)
#error "can't have smp on a 386"
#endif
The umtx stuff used by libthr assumes it can do a cmpxchg in
userland for example. One idea kicked around many years ago was catching the
illegal instruction faults for userland and emulating cmpxchg, but that would
be a good bit of work. FreeBSD now also makes liberal use of 'xadd' for
reference counts (see refcount_*()) so you would need to support that on a
386 as well. There may be other places that I'm not aware of that have
similar assumptions. FWIW, I would probably not be in favor of putting any
patches into the tree if you do manage to get it all working. I suspect the
userbase of FreeBSD/80386 is even smaller than FreeBSD/alpha or
FreeBSD/sparc64 and 80386 support would add a lot of ugly #ifdef's for
miniscule gain.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
