Proc kmsgs now make their changes to cur_tf
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 28 Sep 2011 00:57:47 +0000 (17:57 -0700)
committerKevin Klues <klueska@cs.berkeley.edu>
Thu, 3 Nov 2011 00:36:07 +0000 (17:36 -0700)
commit808d7ae273a02f552de3ade1fc0a06a36c190a95
tree3277e1e14db77181dda59d33fb823f50a8109323
parentc8c00e4f664168b6bdcefdf8bd5bf31573afcaae
Proc kmsgs now make their changes to cur_tf

Previously, when a process management kernel message came in, it's
effects would be felt immediately.  A new TF would be popped, etc.  Now,
all of these messages work on the cur_tf, which is the context that will
run when the kernel is done and either idles or reaches a place it can
run a process (like a PRKM site) (which is where we call
try_run_proc()).

Put another way, instead of actually running the context, we just set up
to run it later.  We can then handle other messages (like a __preempt),
which will just change the cur_tf to do what we want when we attempt to
run them (in that case, it will be to do nothing, since __preempt sets
cur_tf to 0).

Also, __startcore and __notify now return.  __launch_kthread still does
not.
kern/src/kthread.c
kern/src/process.c
kern/src/smp.c