4.6 KiB
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. The means by which processes will locate services is still up in the air as of right now, but I believe I want to implement something similar to (if not compatible with) D-Bus.
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. This config file
will also contain versioning information for compatibility, detailing which
kernel version and architecture it is compatible with.
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 will access services by means of a data bus, possibly similar to D-Bus. In this model, processes would access information from services by making an IPC call to the kernel, which would either serve as a D-Bus server or delegate D-Bus stuff to a special server process. From there, the client process may establish a connection to the system bus, and use that connection to request services.
For example, if a process wanted to request the kernel version, it could
access the service site.shibedrill.Gila, the object path /site/shibedrill/Gila/Kernel,
and the property site.shibedrill.Gila.Kernel.Version. If the same process
wanted to access the vendor ID of a specific PCI device, it could access
service site.shibedrill.Pci, object /site/shibedrill/Pci/Device/07/00/0, and
property site.shibedrill.Pci.Device.Vendor. This property would be present
in all PCI devices, as it would be defined in an interface common to all PCI
device objects in the service's namespace.
Device Drivers
Device drivers, in this userspace concept, are initialized as-needed. If a process requests a service provided by a driver that is not yet running, a privileged process (or the kernel) will initialize a device driver process. If the relevant device is present, the kernel will map the necessary portions of physical memory into the driver's address space, and return information on the mappings to the new driver. If the device does not exist, the message bus will return an error.
How the kernel will recognize whether a device is present, is still unknown. Hopefully, a comprehensive enumeration system can be developed which does not require device definitions to be built into the kernel.
Servers vs. Shared Libraries
Servers and shared libraries serve similar purposes: They make some functionality usable by any process without code duplication. However, there are times when processes and developers should prefer one or the other.
A server should be used when:
- The function must somehow acquire a mutually exclusive lock on a resource.
- The function should complete asynchronously.
A shared library should be used when:
- No resources involved need to be mutually exclusive.
- The function is non-blocking and synchronous.
Hence, servers are very important for things like disk drivers and file system drivers, where non-synchronized writes could cause data loss. It should also be noted that libraries can, and often will, call local procedures from servers. The functionality of calling a procedure will be handled by the standard library and shared across processes.