Invoke initlog from forkret on first user process

Maybe the string boot shouldn't appear in xv6 code?

Remove device mapping from bootpgdir
Remove unnecessary vmenable
Set CPUS back to 2 in Makefile
Passes all usertests

Allocate proper kernel page table immediately in main using boot allocator
Remove pginit
Simplify address space layout a tiny bit
More to come (e.g., superpages to simplify static table)

Very important to give qemu memory through PHYSTOP :(

Passes usertests and stressfs
Seems to recover correctly in a number of simple cases

Variable declarations at top of function,
separate from initialization.

Use == 0 instead of ! for checking pointers.

Consistent spacing around {, *, casts.

Declare 0-parameter functions as (void) not ().

Integer valued functions return -1 on failure, 0 on success.

delete most comments from bootother.S (since copy of bootasm.S)
ksegment() -> seginit()
move more stuff from main() to mainc()

kinit() knows about end and PHYSTOP
map all of kernel read/write (rather than r/o instructions)
thanks, austin

do not keep sorted contiguous free list

find out the hard way why user and kernel must have separate segment descriptors

replace jstack with asm()s

Includes code for TLB shootdown (which actually seems unnecessary for xv6)

this time do it ourselves instead of piggybacking on TLS.
add -fno-pic to Makefile; pic code breaks our fake TLS.

 * rename c/cp to cpu/proc
 * rename cpu.context to cpu.scheduler
 * fix some comments
 * formatting for printout

Some proc cleanup, moving some of copyproc into allocproc.

Also, an experiment: use "thread-local" storage for c and cp
instead of the #define macro for curproc[cpu()].

do Bochs breakpoint and spin in bootasm.S.
not needed in bootmain too.
fix readseg bug (rounding of va).
zero segments when memsz > filesz.
no need to clear BSS in kernel main.
make bootother.S like bootasm.S

Incorporate new understanding of/with Intel SMP spec.

Dropped cmpxchg in favor of xchg, to match lecture notes.

Use xchg to release lock, for future protection and to
keep gcc from acting clever.

Re: why cpuid() in locking code?

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

Final word on the locking fiasco?

Change pushcli / popcli so that they can never turn on
interrupts unexpectedly.  That is, if interrupts are on,
then pushcli(); popcli(); turns them off and back on, but
if they are off to begin with, then pushcli(); popcli(); is
a no-op.

I think our fundamental mistake was having a primitive
(release and then popcli nee spllo) that could turn
interrupts on at unexpected moments instead of being
explicit about when we want to start allowing interrupts.

With the new semantics, all the manual fiddling of ncli
to force interrupts off in certain sections goes away.
In return, we must explicitly mark the places where
we want to enable interrupts unconditionally, by calling sti().
There is only one: inside the scheduler loop.

test: store curproc at top of stack

I don't actually think this is worthwhile, but I figured
I would check it in before reverting it, so that it can
be in the revision history.

Pros:
  * curproc doesn't need to turn on/off interrupts
  * scheduler doesn't have to edit curproc anymore

Cons:
  * it's ugly
  * all the stack computation is more complicated.
  * it doesn't actually simplify anything but curproc,
    and even curproc is harder to follow.