AW: TCR and Stack in the PowerPC implementation

"Christian, Martin, OPEE45" <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.l4ka.general
Message-ID <[email protected]>
Hi Joshua,
thanks for your answer! It made the kernel clearer to me. Especially the
course material you pointed out.

Maybe you or someone else could comment on the following conclusion:

1.) User -> Kernel
a) A cooperative User -> Kernel switch (Syscall) takes these steps:
   -> Save a subset of the register file in a syscall_regs_t frame on
the kernel stack.
   -> Exchange user stack for kernel stack.
   -> Execution continues in kernel mode.
b) A preemptive User -> Kernel switch takes these steps:
   -> Save the whole user mode register file in a except_regs_t frame on
the kernel stack.
   -> Exchange user stack for kernel stack.
   -> Handle exception.

2.) Kernel -> Kernel
a) A cooperative Kernel -> Kernel switch is a usual function call with
some optimization by Joshua.
b) A preemptive Kernel -> Kernel switch does only occur on some bad
occasions, like a Machine Check Exception. Or do kernel threads also get
interrupted by the scheduler?

3.) Kernel -> User
a) A cooperative Kernel -> User switch occurs only if a Syscall returns
with these steps:
   -> Restore registers saved in syscall_regs_t frame.
   -> This exchanges the kernel for the user stack.
   -> Execution continues in user mode.
b) A preemptive Kernel -> User switch can't happen? Or could a user
thread being scheduled while a kernel thread is running?

For the NICTA API I've got to implement a "fork" mechanism, which copies
the register file from a preempted thread A to another thread. Thus I
need to know where the register file is located. If the above conclusion
is right, there might be two possibilities:
a) If A was a user thread, the register file of A would be on top of the
kernel stack of the equivalent kernel thread A.
b) If A was a kernel thread, the register file of A would be somewhere
on the kernel stack of A.

I hope I'm not confusing things anymore ... :-)

Cheers,

Martin.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.