OSDev.org

I'm not exactly an expert on OS design or developement or anything. I only started this stuff myself about 2 weeks ago.

I have programmed Bootloader, A20 line, PMode, and now I am on kernel.
In kernel I have programmed a simple Print function and simple Clear Screen function.

Looks like you were in the same boat as I was at the beginning of this week.

Now I'm not giving you advice here, but I'll tell you where I went from there.

First, I worked on interrupts. Now as mentioned above, you can get by without them, but personally I think they're essential to any modern OS design. This is highly debatable, and it's up to you whether you want to do interrupts or not. But I went ahead and added them. There are some very good tutorials on bona-fide, and you can find plenty of example kernels to learn (copy & paste ;D) from. I wrote some code for reprogramming the PIC, adding interrupt handlers, and I added a little panic routine.

Next, I added paging support. Again, you can get lots of good tutorials on the bona-fide site (actually, note that one of the tutorials loads it's page directories/tables at 0x90000 (I think?) which bumps right into VRam and doesn't work. Maybe load somewhere higher in memory. I loaded mine at 2MB which leaves 1MB for my kernel to grow since it's loaded at 1MB. Plenty of room).

Next, I'm thinking about writing a simple kernel memory allocator. A very very simple implementation of malloc, free and realloc possibly using a doubly linked list of free memory block headers (header contains size and pointer to next and previous headers....and whatever else I might need to add).

Once I get that working, I think a simple keyboard driver might be a good idea, so that I can actually start typing some stuff in.

In the future, if I can get this far. I might add multi-tasking support (although this is way above my head at the moment. Lots of reading up on that if I get that far!)


As mentioned above, what you do in your OS is entirely up to you and depends on how you want your OS to function and what you want it to do etc. But if you're anything like me, you don't have a clue, and really don't care as long as you can get something small working. heh. So maybe the above guidelines will give you some ideas.

Good luck

So OK. I have one more question. What code is going firster?
I mean, that what is in the main first when my kernel.c is called? PIC initialization and remaping, IDT, Print messages, or something else?

And can you tell me what is going by sequence?

you of course decide your own sequence. There are thousands if not millions of things to do, and up to 2^1000000 ways to do it. There is no way I can pick the best of them, neither can you. Make your own choice and tell us how it worked?

I have question again ???
How IDT knows what ISR to choose. I read this manual - http://www.osdever.net/tutorials/interr ... ?the_id=39 and the next two parts, but i didn't understood how programmed idt find appropriate ISR.

The start point of the ISR in memory is encoded in the IDT entry.

So all interupts i need to reprogram myself again in ISR? Or there is programmed interupts and i just need to show the way how to find them?

There's 256 possible interrupts, 32 of which are reserved for processor exceptions.

There are also 16 IRQs that come from the PIC(s), which you can remap to use the interrupts of your choice (Although they must be consecutive).

Exceptions are called automatically by the processor.

Interrupts for IRQs are called when an unmasked IRQ fires.

For every interrupt you must have an IDT entry (The table doesn't have to cover all interrupts, just up to the highest interrupt you use. You'll get an exception if someone tries to use one that's too high).

The IDT entry for a basic interrupt gate consists of a memory address, and a bunch of flags that the processor uses.

When an interrupt/exception is called the processor just gets the appropriate entry out of the IDT (Multiply the interrupt number by 8 and add the base address), performs a few operations (Like checking permissions, storing return address etc), and jumps to the memory address contained in the IDT entry. That memory address should be pointing at your ISR.

You can reuse ISRs as much as you like (Eg I have every interrupt that isn't being used point at a simple "return -1" type ISR. Watch out for exceptions that push error flags), but there must be one present.

All the BIOS interrupts from real mode (I'm assuming that's what you mean by programmed interrupts) aren't available in protected mode. In real-mode there's something called the IVT which is effectively a jump table for interrupts giving entries into the BIOS's 16-bit routines. This can't be used in Pmode, you'll need to use V86 or drop back to real-mode to use those routines.

Hope that clears it up.