Roland> Right. Now think about where the kernel stack for the
Roland> process that is sleeping in the kernel is kept.
Richard> It's the kernel, of course. The scheduler runs in the
Richard> kernel under the kernel stack, with the kernel data. It
Richard> has nothing to do with the original user once the user
Richard> sleeps. The user's context was saved, the kernel was set
Richard> up, and the kernel will schedule other tasks until the
Richard> sleep time or the sleep_on even is complete. At that
Richard> time, (or thereafter), the kernel will schedule the
Richard> previously sleeping task, its context will be restored,
Richard> and it continues execution.
Richard> The context of a task (see entry.S) is completely defined
Richard> by its registers, including the hidden part of the
Richard> segments (selectors) that define priviledge.
I'll try one more time. Let's say a user process makes a system call
and enters the kernel. That system call goes through a few function
calls in the kernel (which each push something on the kernel stack for
that process). Finally, the kernel has to sleep to sleep to service
the system call (let's say it's a blocking read() waiting for some
data to arrive on a socket).
OK, now the scheduler runs, and another user process starts and makes
its own system call, which also goes to sleep.
Now say the data the original process was waiting for arrives. The
scheduler wakes up that process, which is in the kernel, and it
finishes servicing the read. This means it now returns through the
chain of kernel function calls before returing to user space. Each
return in kernel space has to pop some stuff off the stack, and it
better not get mixed up with the second process's kernel stack.
That's (one reason) why each process needs its own kernel stack.
- Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:32 EST