Hi!
I am designing an OS, and I don't know what to do next. Actually there's nothing else working but video-functions. I want to make it clear what to do next!
Is it like: main() function of OS includes the Scheduler and process management? If that's true, does it look something like that in real code:
int main(){
exec(init);
while(1){
//And something here to schedule
}
halt();
}
I'd really like to know. Hey, what programs could you actually execute to processes before implementing the filesystem?
Still I'm asking: what is the order I should do things(mm, main, fs...)???
What to code next?
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:What to code next?
About the scheduler question:
Your scheduling function is called by the timer interrupt.
So it is invoked "via hardware" every few msecs, choses the new task to run, loads it's context and jumps to it's current instruction pointer.
So it is not like a loop inside main that does actively schedule things, but it's in an interrupt handler.
Your scheduling function is called by the timer interrupt.
So it is invoked "via hardware" every few msecs, choses the new task to run, loads it's context and jumps to it's current instruction pointer.
So it is not like a loop inside main that does actively schedule things, but it's in an interrupt handler.
Re:What to code next?
What you put into the main function is up to you (obviously ), but I use it to call the init procedures of basic components (that enable paging, interrupts, scheduler, for ex.), call the global object's constructors (if you are developing in C++ and haven't done that in the asm stub already, as proposed in the FAQ - I call them after enabling paging however) and then I usually put the unit testing code that tortures all the newly added components until they show their bugs. When the kernel is really finished, I'll probably just have set up some required kernel threads (in one of the init functions), get the userspace init process running and then return from kmain() and have the initial thread disposed.OSMAN wrote: Is it like: main() function of OS includes the Scheduler and process management? If that's true, does it look something like that in real code:
cheers Joe
Re:What to code next?
I'd have something like this
Code: Select all
init_scheduler();
sti();
while (1) {
hlt();
}
// Processor shouldn't get here.
Re:What to code next?
Something confuses me in your code: Why do you put the 'hlt' in an infinite loop? When the processor has reached a 'hlt' it will stay there and can only execute another procedure when an interrupt happened, but as soon as you return from this interrupt, it should go to the 'hlt' again. Or did I drink too much today and don't know about the good old x86 anymore?
cheers Joe
cheers Joe
Re:What to code next?
The scheduler is attached to the timer interrupt, so other than dispatching tasks through the scheduler and handling hardware requests, it stays in the hlt state so that the cpu doesn't literaly heat up for nothing.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:What to code next?
so you're combining the init thread and the idle thread in a single one. Smart.DruG5t0r3 wrote: The scheduler is attached to the timer interrupt, so other than dispatching tasks through the scheduler and handling hardware requests, it stays in the hlt state so that the cpu doesn't literaly heat up for nothing.
Re:What to code next?
OK, my fault. I knew what you wanted to accomplish, the point was that I missed that when an interrupt occurs during a 'hlt', the return address points to the _next_ instruction after the hlt. So you need the loop, of course. ::) Thx manual!DruG5t0r3 wrote: The scheduler is attached to the timer interrupt, so other than dispatching tasks through the scheduler and handling hardware requests, it stays in the hlt state so that the cpu doesn't literaly heat up for nothing.
cheers Joe