On Tue, 2005-03-08 at 23:25 +0530, Imanpreet Arora wrote: > Thanks again, but if the whole of the kernel is restricted to couple of pages.
NO. I did not say this. EACH PROCESS'S KERNEL STACK IS A PAGE OR TWO. That is all I said. The kernel can consume hundreds of megabytes of data if it wants. And it does. > Does this mean > > a) the whole of the kernel including drivers is restricted to couple of pages. No. Each process's stack is a page or two. The rest of the kernel is free to use a lot of memory. > b) Or with a more probability, I think what you actually mean is that > whenever there is an interrupt by any driver it runs in either context > of the current process or depending upon CONFIG_IRQSTACKS. Yes, the interrupt runs in the stack of the current process or (given CONFIG_IRQSTACKS) its own stack. Dynamic memory is free to come from all over. > If you could just quote the chapter, in your book which contains > information about this, that would be more than sufficient. That explains what, exactly? Kernel stacks are in Ch2 (1ed) and Ch3 (2ed), I think. > > > b) Or does it mean that a particular stack for a particular > > > process, can't be resized? Yes, a process's kernel stack cannot be resized. > Actually what I asked above was "how exactly does one define and > differentiate kernel stack", as against "user-stack". I think I always > knew it but couple of clouds were coming over after reading your first > mail. Also if each thread has a kernel stack how is it allocated at > first place (alloc_thread_info)(?) The user-space stack is handled by user-space. It is tracked by mm_struct->start_stack. The kernel stack is handled by user-space. It is stored in esp, obviously, while inside of the kernel. And, yes, alloc_thread_info() allocates the stack. Robert Love - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/