BASICFreak wrote:
Ok, I decided to share my plan (or what I have so far of it).
If the plan's goal is education then the plan is good. And even if the goal is a bit more complex then the plan is still good enough just because it's implementation will teach you a lot about the actual goal. In the end you'll just look at the result and understand - here is the place where it is possible to make things better. But until the implementation is close to completeness you have no way to look at and see the
something, which you haven't defined clearly.
It is called iterative approach. You should make iterations and every iteration shows you another bit of the yet unknown picture.
But there's also a bit more efficient approach. And it has a problem. First - there should be a goal. It should be defined clearly. Next there should be a criteria. It defines the test for the goal's achievement progress. If the test is passed then the goal is achieved. Finally there is an optimization. You can assess a number of plans that make the situation when test is passed. And you can select the best performing plan. But again, you need to define what is the performance. Well, it's not a simple approach.
Anyway, the one thing you should understand is the fork on the way of every developer. Would the development be systemic or it wouldn't. I vote for the former, but it's much easier to work with the latter. And the choice is your.
Now about the plan (how to make it a bit more systemic).
BASICFreak wrote:
The file my (FAT) VBR loads is called "FATLOGIC" which is just a 16-bit real mode FAT HDD driver, and a wrapper to load the file "boot/osloader.bin". The beginning of the file has 3 bytes for a jump, a byte for the boot drive number, and 4 SEG:OFF pointers (2 are actually used ATM) then the wrapper and driver information.
Here you try to separate some things from others. You see there's just one need now - to load more bytes. And you load them with the help of the separate entity (fatlogic). But is it optimal? May be. It depends on the criteria (which is still undefined). At least I see here "the driver", which actually performs the very simple task of loading some sectors from hard coded type of file system. Is there a need for such separate driver without really important functionality? First, it is the 16-bit code. Will it be used anytime later? Second, a good driver usually supports one kind of hardware, but supports it in a very efficient manner. Your driver seems to be very generic and it means it won't be efficient. Can we call a generic and inefficient thing "a driver"? If we wish, we can, but... May be it's a good idea to call it "just another stage of the bootstrapping process".
BASICFreak wrote:
These pointers are designated as fopen, fread, fwrite, and fclose - under every boot option, these pointers remain in the same place. And these are designed to be replaced by there 32/64 bit counterparts, in due time.
Here it's probably the portability issue that was addressed with such solution. But it's interesting - do you plan to redirect calls like "fopen" to the "driver" discussed above? Most probably your code with the "fopen" calls will be compiled for 32 or even 64 bit mode, but the driver is for 16 bit mode. May be it worth to think about it.
BASICFreak wrote:
The OSLoader must first detect the CPU Vendor and decide if the CPU is supported by the OS (currently any reply other than "GenuineIntel" or "AuthenticAMD" is considered unsupported) and load the appropriate driver to it's proper location (for use later, after we are done in 16-bit real mode)
Why not to support other vendors? Wouldn't it be better to check for the required processor features instead of the vendor?
BASICFreak wrote:
Currently the only 16-bit modules that I know I will have are SVGA, and MEMORY (the Mem Map from INT 15h)
Here I see a bit different scale of things. Just a tiny bit, in fact. The one call of the INT 15h and the whole blob of the mathematics intermixed with
a lot of low level hardware features for the SVGA to work properly. May be it's good idea to separate some things in the SVGA blob?
BASICFreak wrote:
Once the 16-bit modules here are done, we then jump to the CPU initialization function located in the CPU Driver. Which will run through the CPU ID functions and detect the hardware and load the supported drivers/modules to initialize everything (A20, GDT, IDT, TLB, PM, LM, PSE, PAE, SSE, APIC,... you get it)
I see the "everything" as just a set of small functions like writeGDT or makePMSwitch. The separation of the functionality is a good idea, but if the number of separate functions is too big the mess will be insurmountable. May be it's a good idea to combine some functions in more manageable modules? Modules can be designed according the system goals. The goals can be - switch to protected mode, switch to long mode, installation of interrupt handlers (for the particular mode), initializing of paging, working with the interrupt controller and so on.
BASICFreak wrote:
The very next thing before we actually initialize the CPU is to detect the Boot Medium and load a 32 or 64 bit driver into memory so we do not have to worry about 16-bit real mode interfaces once we have paging and or long mode activated. This also includes loading the file system driver for the next CPU mode.
Here you have many things in one place. I see the need for another separation of concerns here. The concerns are - CPU initialization, boot media detection, boot media read, 32 and 64 bit drivers (how many items here do you plan to create?), the mode switch (at least long mode), paging initialization, file system driver for the "next" CPU mode (is it a hardware thing or actually is the way to read blocks from disk formatted with FAT32 or NTFS or whatever?). So, the number of concerns looks a bit overextended for the such short phrase. But of course, you can do something about it!
BASICFreak wrote:
NOTE: I'm actually unsure what I will have it do if it cannot find the driver for the Boot Medium yet...
Yes, there are also the process transition related concerns. But do you know the plan of the process? What should follow what? And why? I hope you know it in very deep details.
BASICFreak wrote:
So, we are finally ready to initialize the CPU's features - easy enough as the drivers are loaded in...
May be it's really a bit easier if we already have the file system driver. Or memory map. Or SVGA support. May be.
BASICFreak wrote:
Then finally we get to the fun part, setting up a Page Frame Allocator and load the 3 files that make up the Kernel, which are literally 3 INT handlers (Memory, IPC, and Scheduling)
And finally after we have the CPU initialized the only problem remains here is to make these 3 kernel files to do all the stuff a good kernel can do. It's really simple!
There's a bit of sarcasm in my post, so I should ask you not to be too angry. And after the emotions will go away may be it will be the good moment to think about some architecture. But it shouldn't be the OS architecture. I recommend you to start from something simple like bootloader architecture. If you succeed with the simple thing it's greatly increases the chances with bigger things like the YourOS.