OSDev.org

I'm now almost done with kernel thread support, the first step in my multitasking system. The only thing I still need to know is what value to give the useresp field (top of tasks stack, I suppose) when creating a new kernel thread. Can I just allocate a block of memory and then set the useresp to the bottom of it? Or would it be the top, as the stack grows downwards?

Candamir

top, as stack grows downwards.

So, this is for kernel threads... And when running a user process, I'll have to look at the executable image to know what's up with the stack, right?

Candamir

BTW: Kernel threads up and running! The only problem is that when a kernel thread is running, the actual kernel (which hasn't finished it's setup yet) isn't allowed to carry on (only interrupts still work... :-\) because the thread consumes all of the CPU time. Is this due to a design flaw or is that like this always? Could this be fixed by first thing, when initializing the task manager, create a task entry for the kernel (which would be set to low priority when the kernel reaches the idle loop)?

you shoudl have a time interrupt with switches between threads, then you should have an extra kernel thread which is always there which doesn't nothing but infinite loop around a hlt.

Now if you use round robin, you should end up with about 50% cpu usage (one thread burning it up, the other just sleeping). Once you end up with priority you'll have 100% usage again...but only when the thread has work to do which is ideal.

Remember the purpose of a scheduler is to give the CPU useful work to do as much as possible. so 100% usage isn't bad, so long as you have stuff that needs to be done.

proxy

So having a task entry in the linked list for the kernel isn't a bad idea? I would like to be able to do this:

- First part of kernel setup
- Device manager startup, starts a lot of drivers as servers and thus creates many user processes
- Second part of kernel setup
- Idle loop

Candamir

PS: Another aspect of the problem is in another thread by me 'Kernel won't stop running', where I described how I already implemented a part of the solution, but which gives me a page fault when switching to the kernel.

in my OS kenel threads and user threads co-exists seemlessly, the scheduler doesn't even differenciate between the two. Personally, my plan is to use kernel threads for things like bottom half interrupt handlers and the like.

proxy

@proxy: Do you also have the /kernel itself/ registered as a task with the scheduler that gets it's share of time like a common user process?

Candamir

surely any kernel code registered with the scheduler *is* a kernel thread, it's just technicalities of what you call it.