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

## Development Goals

- No custom tooling: Gila should compile, build, and run, without any custom
  languages, syntaxes, formats, emulators, build tools, frameworks, compilers,
  etc.
- Easy to work on: Gila should be easy for developers to understand- not just
  the kernel itself, but the way userspace works together, and the way an ISO
  image is built by the build system. I want people to be able to easily write,
  compile, install, and run a program within a bootable ISO.

## Inspiration

- [Linux](https://kernel.org): A highly featureful monolithic kernel, with
  support for namespacing different kinds of resources.
- [The seL4 Microkernel](https://sel4.systems/): Formally verified, capability
  based microkernel, setting the gold standard for secure kernels. Capable of
  hosting virtual machines as well as normal processes.
- [Redox OS](https://www.redox-os.org/): Linux-compatible microkernel, written
  almost entirely in Rust.
- [Fuchsia's Zircon Kernel](https://fuchsia.dev/): A new kernel and OS by
  Google, which aims to replace the Linux kernel within Android. Features a
  really cool component model for applications/system services.

## Boot Process

After being initialized by the bootloader at a random address, the kernel will
perform some memory management work to start allocating memory for the Userboot
binary. Userboot is a binary executable that will be loaded as a module, and
it will be initialized as the very first process.

The Userboot concept was taken from the Zircon kernel, used in Google's Fuchsia
OS.

Userboot has only one job, and that is to parse the compressed initramfs image
and start the true init system based on the contents of that image. After that,
it can exit. This approach eliminates a lot of code from the kernel, since we
don't have to parse ELF files or perform decompression in-kernel.

The init system will rely only on a small set of kernel & userboot APIs to
bring up other "system software". Userboot will be treated as a part of the
kernel, effectively, allowing the user to build userspace initramfs archives
without having to recompile the kernel.

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.

## Integration as a Full OS

Gila is just a kernel. It does not do much outside of scheduling and memory
management. To make it useful, you must provide a correctly versioned and
formatted initramfs image as a boot module, and include it in the ISO.

The structure of the initramfs will soon be formally defined, and Userboot will
handle parsing it and confirming it is a valid and compatible version before
initializing the full operating system from its contents.

My ideal vision of an OS built on Gila is composed of several "realms", or
privilege levels, which define how information may flow within the system.

- Realm 0, "Kernel Realm", consists solely of the kernel.
- Realm 1, "Driver Realm", holds device drivers and protocol/filesystem drivers.
  This realm provides a solid hardware abstraction layer which the service realm
  may build upon. This is where I would choose to place a memory allocator & any
  standard library implementations, developing them as a part of the driver realm.
- Realm 2, "Service Realm", contains components and services that rely on the
  driver realm or the standard library. This may include things like access
  control, user management, application management, and standard APIs for
  applications to access. This is the software abstraction layer, or framework
  layer.
- Realm 3, "Application/User Realm", contains processes, applications, and
  libraries that are totally untrusted. To perform any functionality they must
  correspond with the Service Realm so it can enforce security policies. Anything
  which can reasonably be written as an unprivileged application should be one,
  to allow for the best isolation and security boundaries.

This structure works well with the Biba security model, which dictates how
information must or must not flow between privilege levels to preserve integrity.
No realm may write data to any realm above it, and no realm may read data from
any realm below it except to arbitrate communication between components within
the same realm.
