Development

So I finally fixed a potentially fatal flaw with the paging subsystem. Before the bottom 4MB's were identity mapped and when a new page table was needed it was allocated from the physical memory manager and the appropriate entries were set by writing to that physical address! big problem after you receive a physical page above the 4MB mark. The new system uses the fractal mapping technique, whereby you map in the page directory into the last entry of itself, letting you address the page directory and all its page tables for the current address space in a linear fashion via the top 4MB's in the 4GB address space (see the picture below). In addition a quickMap() function is available to quickly map in a physical page into the current address space so as we may read or write to it, very useful as this page might be for another address space we are manipulating and will not be accessible via the fractal technique. The kernel is linked to run at the virtual address 0xC0001000 so we have an unused page table entry for the address 0xC0000000, which quickMap() uses to temporarily map in a physical page for access. The INVLPG instruction (only available on the 486 chips or higher) is used to flush the specific TLB entry (0xC0000000), incurring a mild performance hit. The new code is up in CVS.



The above diagram shows the typical address space layout for a process. Each process has its own unique address space, defined in the top 4MB's via the fractal paging technique. The kernel at the 3GB mark upwards is common and mapped accross all processes. Below the 3GB mark is the unique address space for the process. Below the 16MB mark is physical memory eligable for DMA operations.

Updated the website to encompas more than just the development blog, look to the right and you can see you may navigate to sections like screenshots and download, sweet!

Released 0.5.0 with the near finished process manager subsystem and lots of bugfixes. A simple user shell application is included along with a test application. Each virtual console has an instance of the shell spawned on it so you can finally interface with the kernel via a pretty good set of system calls. Each process spawned is a user mode process (ring3) with its own address space so theirs good separation and protection between multiple processes in the system. The test application lets you perform some illegal operation to stress test how stable the kernel is, so you can perform page faults, general protection faults and the like at will. The kernel process (ring0) after initializing the kernel itself and spawning the initial shells turns into the systems idle process. I have tested 0.5.0 on VMWare, Qemu and Bochs and it seems to be pretty stable. Their are some known issues with the FAT driver; still no write support and some small bugs with file/path naming. Also virtual mount points are not included within list operations. Pressing F5 at any time will display the schedulers current process table.

Download the source code or binarys here:
AMOS 0.5.0 release (SourceForge.net)

And finally some screenshots of AMOS running, click to enlarge...


Spawning the test.bin application and generating a GPF exception.

Manipulating the file system.

Getting ready for a big release next week which will include the near finished process manager. We can now spawn user processes (ring3) . The kernel is fully reentrant and system calls are working. Synchronization between critical section is achieved through mutex's (read spin locks). A simple user shell for interfacing with the system is in place on all virtual consoles. Checkout CVS as all the code is up their anyway.