OSDev.org

Hello.
Im working on a kernel and now i want to add multitasking support for it. I haven't decided yet which type of switch to use (hw or sw). But I have some questions about the memory management for the tasks.

First I want to ask about the stack. Is it right that I have one kernel mode (ring 0) stack, and a stack for each user task (ring 3)?
Right now the kernel has not a good address for the stack, I'll fix that, but should I use a stack segment? I seems to work fine without one.
But if I understand it right with the stacks the kernel needs to manage the tasks and their stacks in memory. How about putting the task's stack right after the task's code in memory?

If I got that right I need to allocate memory for the tasks and put them there. Right now I have kmalloc/kfree functions which allocates memory from a static heap (not good, but will fix that in the future).
This confuses me, should I use kmalloc/kfree for allocating memory for my tasks? Then I can have the heap take all physical memory. but... I don't even know exactly what a heap is But if I would guess, the heap is used for kernel structures and stuff, and the task's memory should be handled on some other way than kmalloc/kfree.

Sorry for so much questions, but I would be glad if someone would help me get a better understanding on this.

Thanks!
/Norton

i think you might like reading http://www.mega-tokyo.com/forum/index.p ... eadid=5844 ...

the scheme 1 kernel stack and N user stack for N user threads is not the one i would suggest. It's better to have N x {1 kernel stack + 1 user stack}, allowing any thread to be either in kernel or user mode independently from other threads state.

The only 'real' restriction on SS is that it holds a selector towards a WRITABLE DATA segment and that the stack segment's base matches the DS segment base if you want to execute C code. That being said, you're free to do whatever you want with segment limits.

Afaik, using the k+Nu stacks model means you cannot suspend a thread while it's in kernel mode, and i wouldn't like to program in such a model.

Note that in N(k+u) model, a stack (either kStack or uStack) for process X doesn't need to appear in process Y's address space, so it's not necessary to use kmalloc/kfree: you can use a system that allocates virtual addresses from the 'process-specific' virtual addresses range and then fill them so that they become stacks.

HTH.

hi, do you have any idea about how big should a kernel stack be? what factors might determine kernel stack size?

well, I have another question. I might be wrong but anyway... I do not understand really how two user tasks be in a kernel code at the same time. I think a thread can be dispatched at timer interrupt's scheduler, so when a user thread is dispatched, it is DEFINITELY at some very distinct point, I mean at the task switching instruction. Besides since you clear interrupts while you are handling them there is no way that a user task is interrupted while handling another interrupt in kernel code. as a result we can use same ring0 stack at every place other than timer interrupt that is the scheduler code, right? At timer interrupt, we can get around this problem by simply doing some kind of trick that is you can use another dedicated stack. I am currently doing in that way and there is no problem. I might have misunderstood, if so ignore me... ;D

@ 'how big a kernel stack should be ?'
that really depends on what you do in kernel mode. So far, 16KB have been enough for me, but i have a microkernel design, so i do not envision to have things like network processing or filesystem handling within the kernel stacks ...

@ 'can we use One True Kernel Stack for all processes ?'

I'm not sure i got your point completely, but here's a case where k+Nu causes trouble.
Imagine process A issues a 'read file' call. The kernel-world stack is retrieved and the kernel sets up things until it has to wait for a disk response (thus yielding the thread and calling the scheduler which can pick another thread). The problem here is that at the time of the thread switch, the content of the kernel-world stack captures the 'operation in progress' ...

What will you do if the process that executed just before A is resumed has (for instance) been preempted rather than issueing a read file too ?

It is very unnatural to write programs so that operations can be continued after the thread is resumed without assuming its former stack is still there. It *can* be done (that's much like 'Continuations' in languages like scheme/lisp), but it really adds complexity to the design, especially if you have no support for such constructs in your programming language.

ok, I understand your point, at first sight it also seems to me that k + nu does not work but when I think about it more deeply, I still have doubts about it... Especially this device management is still far away from me and when I think about how I can implement a floppy read for a user task, I am in a complete confusion, so you are most probably right. (but for the time being. ;D)