Kernel message nested function scoping
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 9 Nov 2012 16:09:47 +0000 (08:09 -0800)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 9 Nov 2012 17:03:10 +0000 (09:03 -0800)
commitfbf207651b510d101546b180449ac02a89d29b57
treeb480cdecb95848381c8591c847c452b799d02527
parent42f944152c301c2ac20ca26d157cec9527018d6c
Kernel message nested function scoping

Sometimes when we define kernel message functions inside another
function, the compiler will put function's code on the stack.

This happens now with the __test_cv functions in testing.c.  It doesn't
seem to do it for others, and as far as I can tell, it will do so when
the function references stack variables.  Makes sense, since
stack-relative addresses are the only way to know where the variables
are.

Anyway, I don't know if the compiler will ever put those functions on
the stack for other reasons.  Since it's probably a bad idea to refer to
items after their scope disappears, move the KMSG handlers outside the
scope of their caller.  If you don't, be careful.

It's tempting to use some form of synchronization to keep the
encapsulating function alive til the handlers complete, say with a flag
variable or something (which we tend to do anyways).  However, there's
still a slight race after the handler function signals and before that
code returns/pops its stack frame.
kern/arch/riscv/console.c
kern/src/kthread.c
kern/src/monitor.c
kern/src/syscall.c
kern/src/testing.c