# 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.

Conventions for local procedure calls and message busing will be worked on
soon.

## 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.

## 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.