On Sun, 03 Oct 2004 08:41:29 +0800, Bao zhao <paozhaokeats@xxxxxxxxxxx> wrote: > context_switch function is the only one which calls switch_to, and the first > argument and the third argument are same. Is it not redundant? Page 92 of Understanding the Linux Kernel states: ``You might easily guess the role of prev and next - they are just placeholders for the local variables prev and next - but what about the third parameter last? Well, the point is that in any process switch, three processes are involved, not just two. Suppose the kernel decides to switch off process A and to activate process B. In the schedule() function, prev points to A's descriptor and next points to B's descriptor. As soon as the switch_to macro deactivates A, the execution flow of A freezes. Later, when the kernel wants to reactivate A, it must switch off another process C (in general, this is different from B) by executing another switch_to macro with prev pointing to C and next pointing to A. When A resumes its execution blow, it finds its old kernel mode stack, so the prev local variable points to A's descriptor and next points to B's descriptor. The kernel, which is now executing on behalf of process A, has lost any reference to C.'' [ Quoted text from Understanding the Linux kernel, second edition. O'relly and associates. ISBN: 0-596-00213-0. RRP 49.95USD, 77.95CAN. http://www.oreilly.com/ ] So what it's getting at is that during context switch, the kernel stack and current process switches so the local variables available within the function doing the switch also change. This needs to be accounted for ahead of time by providing the kernel with enough information to deal with switching processes back at a later point in time. It's really worth picking up a copy of UTLK - it's only 12.50GBP or so in bargin shops here, which works out at around 20USD for the second edition which covers 2.4. Much of that is relevent for 2.6 because the fundamental concepts have not changed, just lots of bits in the vm and scheduler which aren't a major hurdle at the outside. rml does a good job with his book but (probably in an attempt at differentiation) he avoids some of the topics the UTLK goes in to in more detail (but this also means his book is more practical on the train - people I work with generally agree that smaller manageable books are often much more useful than big oversized ones just from a practical viewpoint). I do have lists of points I've spotted in several kernel books that I keep planning to put online at some point - perhaps I can abuse the kernelnewbies wiki for this purpose. Jon. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
