On Wed, 23 Sep 2009, John Baldwin wrote:
On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote:
John Baldwin wrote:
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
No, it actually does not. The in-kernel version of cmpset for 386 was to
disable interrupts while doing a cmp and jmp around a mov (even 386's have
preemption, so you do have to disable interrupts). You can't do that in
userland (cli is a privileged instruction), which probably mandates doing a
cmpxchg emulator in the kernel for userland code. That and disabling
interrupts is actually far less efficient than spl() for a UP 80386 machine.
I suspect newer kernels will run slower on an 80386 than 4.x.
Another issue that I know affected Linux is that the 386 would allow
kernel code (CPL 0) to write to a page that was marked read-only. The 486
and later would generate a page fault. Linux takes advantage of the 486
behavior to avoid having to do explicit access checks when copying to user
space, though AFAIK it checks the CPU at boot time to decide if this can
be done. I haven't checked whether FreeBSD uses this feature, but it
would be another thing to watch out for.
--
Nate Eldredge
n...@thatsmathematics.com
_______________________________________________
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"
