I think since my last post about the project quite a lot has happened. As some fundamental changes, starting with v1.0.0 I ported the whole project to x86-64 (yes I dropped x86 support) and switched to Limine as the bootloader.
Also, ƒenster, the window server, moved to a standalone embedded project that others could possibly use to integrate in their OS.
Main improvements/changes
- Hardened a lotof things in the kernel, specifically memory management and process lifecycle. There is now a proper cleanup (finally) on process exit and failed allocations are rolled back more safely. Also cross-processor TLB shootdown now and more validation on ELF loading.
- The user-space filesystem driver interface is now more mature and has been extended for additional operations (see details below).
- AHCI driver is usable and interfacable with the libblockdevice library. fatdriver implementation covers basic fat formatting, reading and writing
- There's an ACPI driver and some power handling
- Improvements to the PS/2 driver to make it actually usable on real hardware
- A little notepad-style editor
- And probably the coolest addition, there is now an installer that allows disk formatting, copies over files from the ramdisk, installs Limine and makes the drive bootable
- More CLI commands like "file", "folder", "disk" and "volume"
This whole concept has lived in the project for a long time but was never mature enough to have a full end-to-end process. It now is, so I want to give a bit more context on why the project might be interesting, at least a little bit. There's more to Ghost than a fancy UI lol. Since it is a micro-kernel, much of the work is happening purely in userspace:
The drivers communicate through IPC via messages or shared memory. The component dependencies documentation shows diagrams on the component interaction.
As an example I'll elaborate a bit on storage:
On boot the ahcidriver uses libpci to talk to the pcidriver to find an AHCI controller. It then identifies the available disks, sets up DMA and calls the devicemanager to register a device of type G_DEVICE_TYPE_BLOCK. The devicemanager then populates the information about the new disk onto a message topic device which others can listen to.
The storagemanager is listening to these announcements; it waits for appearing disks - this disk event carrying the driver task id - and then uses libblockdevice to interface with the ahcidriver - not knowing what it actually is, just fulfilling this contract. The storagemanager keeps track of logical disks and volumes. So it uses libblockdevice to identify what is on the disk and the partitions are announced as volumes on the volume topic.
The fatdriver in turn listens on the volume topic since it is interested in new volumes. When it sees a new volume, it probes it (using libblockdevice to talk to ahcidriver) and then it uses libstorage to interface with the storagemanager to request a claim on the volume. If the volume can be claimed, the fatdriver uses a syscall to the kernel (since VFS is in the kernel) to register a mountpoint and tell the kernel, that it is the handler for any requests.
After this whole flow, when a process is trying to read a directory or open a file, the kernel then sends messages to the fatdriver directly as it is the "filesystem delegate" for this filesystem. The driver then does whatever is necessary (talking to ahcidriver, reading and interpreting sectors) to do the respective action.
The main advantage of this architecture is, that the system is very stable - I barely have complete crashes - but obviously, there's a huge amount of communication going on between the processes. Some of the responsibilities are not perfectly separated; for example the devicemanager is currently also the one starting video drivers. It might still be in the future but the mechanism isn't very elaborate.
The documentation explains more details about the driver architecture, storage management and how filesystem delegates work.
Some screenshots
The installer:
In progress:
And yes, it's running and installing on real hardware
The next thing I'm working on is a e1000driver and a networkmanager that is responsible for socket resources. Since I'm not interested in writing my own TCP/IP stack I'm planning to port lwIP here and likely bearssl for TLS handling. I'd love to get self-hosted, but I don't want to have bash lol.
Best greets
Max
