Samsara is a hybrid language based kernel coded in the custom programming language Yggdrasil, itself being an object-oriented programming.
At its most basic, Samsara is nothing more than bindings written in Yggdrasil, and pretty much everything else is a module that can be replaced. The kernel can be packaged with as few or many modules that are needed, load modules on startup, and even run modules outside of kernel space, the only modules that are necessary are the three core modules listed below, which have to be present and running in kernel space. There are two types of modules: executing, generally drivers and the core modules, and non-executing, generally support modules and setting modules. Executing modules are registered with the scheduler (see Process Communication Server in the core section) and are considered a kernel level process, whereas non-executing modules are not registered with the scheduler. All executing modules need to follow a supervisior tree style architecture: a module will spawn in worker threads will spawn in worker threads that will run until either a successful completion of the task or the will or until an error is encountered. A value is returned when the the worker thread terminates, including errors which themselves are values. A submodule can also be called to spawn in its own threads that it then manages, and worker threads can also spawn and manage multiple threads.
All code that changes based on the hardware is stored in this module: most of the assembly code, firmware interactions, and hardware abstraction layers. The architecture module can boot code to allow the kernel to self boot and even recompile itself on startup.
The core modules are the 3 modules central to the working of Samsara and Yggdrasil that have a primary job and a secondary job that is an outgrowth of the primary job: Process Communication server (PCS) which manages scheduling and inter-process communication (ipc) and networking, the Memory Security server (MSS) which manages the memory and security permissions, and the File Resource server (FRS) which manages the filesystem and devices. The core modules have to be present in the kernel and running in kernel space, but can be replaced as long as the core modules implement the necessary Yggdrasil bindings. The 3 core subsytems start there execution in the order of: PCS, MSS, FRS, and loads in the opposite direction due to the former task needing the PCS and the latter task needing the FRS to do any special loading at start time (downloading modules off the network or recompiling and updating modules).
- Process Communication Server (PCS): The PCS manages process, schedules threads, and manages IPC and the software stack of networking. The PCS keeps track off the process and makes requests to the other modules when a process is starting up. In kernel space, process must obey the supervisor tree structure to be executed: A supervisor spawns a worker thread which executes some algorithm and returns a value to its supervisor, with supervisor being the module itself, with threads, which can spawn their own threads, and submodules below it. The supervisor then decides what to due with error: whether to ignore it, relaunch the thread, or to halt itself and its children and return the error to its supervisor, and since the PSM calls every executable module, it is the ultimate error handler for the whole kernel. Device drivers and other services running outside of kernel space are not subject to the same restriction. The secondary job of th PCS is to manage interprocess communication and the software side of the network stack (the hardware side is handle by the network driver) due to networking being basically IPC between programs on different computers. All IPC is done via mailboxes and messages passed between them: Information written to a mailbox is packaged into a message with a destination mailbox that the PCS delivers it to where it can be read by the destination process. The buffering, connections to other mailboxes, and the type of messages passed can all be configured to change the behavior of the mailbox, allowing for most of Unix's IPC (exempting semaphore) and even files to impersonated (e.g. using a mailbox to impersonate a jpeg file to allow for streaming of image data between computers)
- Memory Security Server (MSS): The Memory Security Server manages memory and controls security access to and by various resources and entities. The primary reason for the memory manager to handl security is that it basically acts as a security system for memory and a lot of security, such as permission rings, involves memory. The MSS uses Permissions and Accessors to manage access to resources. Accessors are given permissions over files and resources, which are files (see File Resource Server), which tell the accessor what they can do with the file or memory section (read, write, and execute are the common ones). Accessors can be users, executing programs or devices.
- File Resource Server (FRS): The FRS primary job is to manage the overall file system and provide an interface for file systems to be mounted, in same way as the Virtual File System in Linux. The FRS' secondary job is to manage the hardware devices, due to the Unix's "Everything is a File". The FRS extends Unix's file interface by treating hardware devices and virtual environments (virtual machines and container) as if they were storage devices, with file systems being their interface (e. g. the framebuffer and processing cores of a graphics card or the ports of a network card are files in a file system). Every filepath is also a url: the schem is the filesystem, the host is the device, and the query is a Yggdrasil statement that can change the way the file is accessed (See Yggdrasil and Syscalls), and if the file system is obvious, then the device can be used in the scheme instead or the scheme can be ommitted all together
Secondary modules are all the none core modules added to the kernel, they might be device drivers, severs for extra kenel functionality, libraries for other module, or data stores for other modules.
A table based language that will be used for both writing the kernel and making syscalls to it. Yggdrasil takes its main ideas from primarily Rust, Lua, and Lisp, with some influence from C++, Zig, and Java. Everything is represented as a table: files, memory sections, and threads are all tables. Structs and enums are also derived from tables, with structs being the rows and enums being the columns. Encapsulation is enforced using permission modifiers (a mirror of the file permissions) on entries on the table and functions can be added as entries in the table, allowing them to modify the table and serve as methods, and entries can be defined by other entries, making them properties. Traits are contract types that guaraentee that certain permissions, properties and methods are present in the table.
Like all other Unix-like operating systems, Samsara starts the init system which starts every other process. However the init system is also tasked with setting up the userspace with the assistance of the MSS, which is done mostly on startup by mounting resources and changing runtime settings in the kernel. The biggest change by far is deciding what drivers and services are ran and where. On boot the kernel loads its core modules, then secondary module, then the init system which then then loads any userpace level drivers and services and tells the kernel where it would like them to run and even to unload certain modules. The places the init system can put drivers and services, including itself, are: in kernel space (ring 0), userspace (ring 3) or the ring(s) inbetween (1 and 2). If a ring is used inbetween userspace and kernel space then an api/abi can be provided to act as shell (this is not necessary as the ipc can also be used). The init system can also reconfigure how the kernel behaves by talking to the core modules: requesting the PSM remove itself from the process table will make the kernel run in cooperative multasking mode, a request to the MPM can be made to run the kernel in the language-based mode, and specific mounting can change how the request can change how the file hierachy is organized. Many of these features can also be locked down by changing flags in the source code or installing a setting module that changes the flags.
- Philipp Opperman's Rust Kernel Blog
- Ed of Low Level Learning's "rust runs on Everything (no operating system, just rust)"
- Nir Lichtman's "Making a Bootloader using x86 Assembly
- Redox OS
- Wikipedia on everything from plan 9, Unix/POSIX standards, Linux, language-based operating systems and more.
- Masen's "How to make a simple boot loader that reads a kernel into memory!
- Osdev wiki
- "EFI Based Operating System Bootloader Series" by ThatOSDev Archive
- Queso Fuego's "UEFI Programming in C"
- sphaerophoria's "Writing an operating system"
- "Rust OS" by Uncle Scientist Building an OS by nanobyte
- "Making an OS" by Daedalus Community