genuine cpu I386_CPU kernel support

[Julian Elischer]

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