Overwiew

This document presents a global overview of NightOS. It is only a simplified representation of the system, but allows to better understand its architecture and organization.

The referenced documents are mostly technical overviews themselves, which is why links to their associated specification document are also provided (marked as (specs)).

Note that this is only an overview, and as such many topics will not be covered by this document. For more informations, refer to the global document.

Program executions
Permissions
Hardware access
Hardware drivers
Hardware access performances
Filesystem access
Data loss prevention
User interface
Users management
Children protection
External security
For developers

Program executions

NightOS doesn't allow to run standalone binaries. Every running code is either:

Part of the system, as the kernel (specs) itself or as a system service (specs).
Part of an application (specs)

System services are immutable and run for the entire system's lifespan, while applications can be opened and closed at anytime, and can also run as multiple instances in parallel.

Permissions

While the system has every right on the system itself, applications are restricted and can do almost nothing by default.

Capabitilies can be granted through permissions (specs), which are designed to allow precise control on what an application can do or not, while requiring as few user interactions as possible.

Hardware access

Hardware access is performed through two layers:

First, the kernel detects and enumerate (specs) hardware devices
Then, hardware is accessed through the hardware service (specs)

Hardware drivers

Unlike most operating systems, hardware drivers are simple applications with no specific integration in the kernel.

Any application can register itself as a driver (specs) using the hardware service (specs).

The relevant driver for each hardware device is selected using various criterias (specs).

Hardware access performances

Hardware access is performed through syscalls (specs) and signals (specs), which use CPU interruptions.

The access process is often:

A userland process notifies a system service
The system services contacts the hardware service (specs)
The hardware service contacts the relevant (specs) driver (specs)
The driver performs the requested task by communicating with the hardware through the hardware service
The action's result is then transmitted to the hardware service, which then transmits it to the system service, which in turns transmits it to the userland process

Although this process can seem a bit long, CPU interruptions and forced threading (specs) makes the theoric latency low enough for intensive use.

Filesystem access

Accessing and managing filesystems and their content is faster than common hardware operations thanks to direct storage access (and direct driver access for worst-case scenarios).

The typical process involves communication with the filesystem service which communicates directly with storage devices.

For filesystems that aren't natively supported, a filesystem interface is involved to communicate with the storage driver service, which then communicates with the hardware service. This involves a higher latency, but is only limited to edge cases and remains in an acceptable range of performances.

NightOS documentation