gila/DESIGN.md

Design Outline

Gila is a microkernel, and almost all functionality of the OS is relegated to "server" processes. A server is a process that provides a specific functionality, using a kernel-provided interface, and it is given a "seat" by the kernel which processes may query to reference it and invoke its functions.

Boot Process

Gila initializes as a bare kernel, with the bootloader providing an init RAM filesystem in the form of a .tar.lzma archive. The kernel reads this file, and launches an init process (/system/bin/init). The init process has its own configuration file located at /system/cfg/init.toml, which should detail the steps needed to bring the system up to a multi-user status.

If the init system needs to access a filesystem, it must first get the handle of the filesystem server. If the filesystem server is not running when this handle request is made, the kernel will launch the server before returning its handle. From there, the filesystem server will request the handle of the disk driver that corresponds to the requested filesystem. The kernel then launches the disk driver server, and assigns it a seat based on the device it drives, granting it access to the memory region responsible for that device.

The benefit of this approach is threefold:

• The system does not need to include a filesystem OR disk driver, if neither the disk nor the filesystem are read or written.
• The driver or filesystem server can crash, and the whole stack can recover.
• The user or developer can trivially introduce new drivers without a reboot. This goes for filesystem drivers AND disk device drivers.

The system, hence, can be configured in two ways:

• The drivers can all be included in the initramfs for diskless operation.
• The bare minimum drivers needed for disk access are included in the initramfs, and all other drivers are included in the root filesystem.

APIs

Processes access services similarly to the way the init process accesses data from the file system. The process requests the ID of the server that performs the function, and then communicates with it via IPC and shared memory regions. APIs are to be defined in the standard library.

Device Drivers

Device driver assignment is performed like so:

• The kernel obtains necessary hardware topology info from ACPI or the DTB.
• For each device, the kernel spawns a driver process based on a compatibility list that details which drivers work for which devices.
• The driver process, when it initializes, requests information from the kernel about the device. The kernel maps relevant regions of physical memory into the process's memory space, and returns information on the new mappings to the process.
• The driver then makes its functions available via IPC and shared memory.
• The kernel stores information about the driver to avoid spawning duplicates.