The correct order of evolution

[8infy]

Hey everyone!

I'm making an OS and right now I have the following things done already:
Basic FAT32 bootloader (doesn't even fetch the memory map), GDT, IDT, basic exception handling, IRQ handling with remapped PIC, PIT.

Right now i'm confused as to where to go next.
Current options I'm considering:
1. Starting multiple cores (perhaps too early? but I really want to do it asap)
2. Memory allocation
3. Virtual Memory/Paging (perhaps related to the above)
4. Something else?

Thing is, once I have paging enabled it would probably be more difficult to enable multiple cores and find the APIC tables (or whatever they're called) and do other type of bootstrapping.
Or am I wrong? What would you recommend I do?

Thanks.

[iansjack]

There's no "correct" order, but I don't think that you can do much useful until you have determined what memory is available and have some means to allocate it and record it's use. If you are ever going to use paging (why wouldn't you), it's probably a good idea to implement it now before you have to go back and rewrite what you have already done.

I guess that you are only targeting 32-bit processing, as 64-bit requires paging. I think that's a mistake that will limit what you can do and make it much harder.

Personally, I'd put multiple cores on the back burner for now. They raise a whole host of new problems that are probably better left until you are more experienced.

I'm presuming that you have already written code to handle basic i/o devices such as keyboard, screen, and external storage. What about multiple tasks?

[8infy]

There's no "correct" order, but I don't think that you can do much useful until you have determined what memory is available and have some means to allocate it and record it's use. If you are ever going to use paging (why wouldn't you), it's probably a good idea to implement it now before you have to go back and rewrite what you have already done.

I guess that you are only targeting 32-bit processing, as 64-bit requires paging. I think that's a mistake that will limit what you can do and make it much harder.

Personally, I'd put multiple cores on the back burner for now. They raise a whole host of new problems that are probably better left until you are more experienced.

I'm presuming that you have already written code to handle basic i/o devices such as keyboard, screen, and external storage. What about multiple tasks?

I'm not saying i'm not gonna do paging, it's definitely one of the high priority things atm, the only question is do it right now or after other bootstrapping tasks such as starting the APs.

And no i haven't started multitasking exactly because I don't want to rewrite everything to make it work with multiple cores.

[iansjack]

I think it's a mistake to try and get multiple cores working without a robust memory allocation and tasking model in place. But that's just my opinion.

[8infy]

I think it's a mistake to try and get multiple cores working without a robust memory allocation and tasking model in place. But that's just my opinion.

Yeah that makes sense. But still, does that mean I have to rewrite the scheduler completely afterwards?

[pvc]

…But still, does that mean I have to rewrite the scheduler completely afterwards?

Actually… no. The part that needs most changes is interrupt controller related stuff. Legacy PIC code goes out the window. You have to use APIC.
Legacy PIC has no way to handle SMP. You also need proper locking mechanisms in place, like spinlocks, mutexes, semaphores, etc. Scheduler itself doesn't really change much.
If I was you, I wouldn't bother with SMP for now. IMO, proper memory management would be the next thing to implement. Almost every other feature requires some sort of dynamic memory allocation mechanism. Also, paging dictates how you are going to handle hardware devices that are using MMIO and DMA. It's quite tricky part to implement, but it's essential.

[8infy]

…But still, does that mean I have to rewrite the scheduler completely afterwards?

Actually… no. The part that needs most changes is interrupt controller related stuff. Legacy PIC code goes out the window. You have to use APIC.
Legacy PIC has no way to handle SMP. You also need proper locking mechanisms in place, like spinlocks, mutexes, semaphores, etc. Scheduler itself doesn't really change much.
If I was you, I wouldn't bother with SMP for now. IMO, proper memory management would be the next thing to implement. Almost every other feature requires some sort of dynamic memory allocation mechanism. Also, paging dictates how you are going to handle hardware devices that are using MMIO and DMA. It's quite tricky part to implement, but it's essential.

Alright, thanks. Memory management it is.