cur_proc broken up into owning_proc and cur_proc
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 3 Oct 2011 23:18:34 +0000 (16:18 -0700)
committerKevin Klues <klueska@cs.berkeley.edu>
Thu, 3 Nov 2011 00:36:08 +0000 (17:36 -0700)
commitd705057abc584ae9a6235a5a00f5623501d7af13
tree0b91f49dadd0cb91e2052a9cc75c3febb940362e
parent77079f32594d978d69f6574403d0b2d772a41a36
cur_proc broken up into owning_proc and cur_proc

It's important that our interrup/kmsg handlers do not adjust current out
from under regular kthread code (or whatever was running there before).
This led to splitting up cur_proc.

pcpui->cur_proc (current) is now only what context is loaded, and not
what process owns the core (owning_proc).  This distinction wasn't clear
before.  owning_proc tells us which process to run, and cur_tf tells us
what trapframe to pop/run.

All proc mgmt kmsg handlers now work on owning_proc, instead of some
combination of cur_tf or cur_proc.  cur_tf has no meaning without an
owning proc.  Earlier, we used cur_tf as a signal to run things.  now we
use owning_proc.

Read the documentation for more details.
Documentation/kref.txt
Documentation/process-internals.txt
kern/include/process.h
kern/include/smp.h
kern/src/process.c
kern/src/resource.c
kern/src/smp.c
kern/src/syscall.c