9fd9f80431
rtm wrote: > Why does acquire() call cpuid()? Why does release() call cpuid()? The cpuid in acquire is redundant with the cmpxchg, as you said. I have removed the cpuid from acquire. The cpuid in release is actually doing something important, but not on the hardware. It keeps gcc from reordering the lock->locked assignment above the other two during optimization. (Not that current gcc -O2 would choose to do that, but it is allowed to.) I have replaced the cpuid in release with a "gcc barrier" that keeps gcc from moving things around but has no hardware effect. On a related note, I don't think the cpuid in mpmain is necessary, for the same reason that the cpuid wasn't needed in release. As to the question of whether acquire(); x = protected; release(); might read protected after release(), I still haven't convinced myself whether it can. I'll put the cpuid back into release if we determine that it can. Russ |
||
---|---|---|
.cvsignore | ||
asm.h | ||
bio.c | ||
bootasm.S | ||
bootmain.c | ||
bootother.S | ||
buf.h | ||
BUGS | ||
cat.c | ||
console.c | ||
cuth | ||
defs.h | ||
dev.h | ||
dot-bochsrc | ||
echo.c | ||
elf.h | ||
exec.c | ||
fcntl.h | ||
file.c | ||
file.h | ||
forktest.c | ||
fs.c | ||
fs.h | ||
fsvar.h | ||
grep.c | ||
ide.c | ||
init.c | ||
initcode.S | ||
ioapic.c | ||
kalloc.c | ||
kbd.c | ||
kbd.h | ||
kill.c | ||
lapic.c | ||
ln.c | ||
ls.c | ||
main.c | ||
Makefile | ||
mkdir.c | ||
mkfs.c | ||
mmu.h | ||
mp.c | ||
mp.h | ||
Notes | ||
param.h | ||
picirq.c | ||
pipe.c | ||
pr.pl | ||
printf.c | ||
proc.c | ||
proc.h | ||
README | ||
rm.c | ||
runoff | ||
runoff.list | ||
runoff.spec | ||
runoff1 | ||
sh.c | ||
show1 | ||
sign.pl | ||
spinlock.c | ||
spinlock.h | ||
stat.h | ||
string.c | ||
swtch.S | ||
symlink.patch | ||
syscall.c | ||
syscall.h | ||
sysfile.c | ||
sysproc.c | ||
timer.c | ||
toc.ftr | ||
toc.hdr | ||
trap.c | ||
trapasm.S | ||
traps.h | ||
TRICKS | ||
types.h | ||
ulib.c | ||
umalloc.c | ||
user.h | ||
usertests.c | ||
usys.S | ||
vectors.pl | ||
wc.c | ||
x86.h | ||
xv6-rev0.tar.gz | ||
xv6-rev1.tar.gz | ||
xv6.pdf | ||
xv6.ps | ||
zombie.c |
xv6 is a re-implementation of Dennis Ritchie's and Ken Thompson's Unix Version 6 (v6). xv6 loosely follows the structure and style of v6, but is implemented for a modern x86-based multiprocessor using ANSI C. ACKNOWLEDGMENTS xv6 is inspired by John Lions's Commentary on UNIX 6th Edition (Peer to Peer Communications; ISBN: 1-57398-013-7; 1st edition (June 14, 2000)). See also http://pdos.csail.mit.edu/6.828/2007/v6.html, which provides pointers to on-line resources for v6. xv6 borrows code from the following sources: JOS (asm.h, elf.h, mmu.h, bootasm.S, ide.c, console.c, and others) Plan 9 (bootother.S, mp.h, mp.c, lapic.c) FreeBSD (ioapic.c) NetBSD (console.c) The following people made contributions: Russ Cox (context switching, locking) Cliff Frey (MP) Xiao Yu (MP) The code in the files that constitute xv6 is Copyright 2006-2007 Frans Kaashoek, Robert Morris, and Russ Cox. ERROR REPORTS If you spot errors or have suggestions for improvement, please send email to Frans Kaashoek and Robert Morris (kaashoek,rtm@csail.mit.edu). BUILDING AND RUNNING XV6 To build xv6 on an x86 ELF machine (like Linux or FreeBSD), run "make". On non-x86 or non-ELF machines (like OS X, even on x86), you will need to install a cross-compiler gcc suite capable of producing x86 ELF binaries. See http://pdos.csail.mit.edu/6.828/2007/tools.html. Then run "make TOOLPREFIX=i386-jos-elf-". To run xv6, you can use Bochs or QEMU, both PC simulators. Bochs makes debugging easier, but QEMU is much faster. To run in Bochs, run "make bochs" and then type "c" at the bochs prompt. To run in QEMU, run "make qemu". Both log the xv6 screen output to standard output. To create a typeset version of the code, run "make xv6.pdf". This requires the "mpage" text formatting utility. See http://www.mesa.nl/pub/mpage/.