Flint

Terminology

Flint uses three conceptual execution domains:

Kernel space

The domain in which the Flint kernel executes.

Kernel space contains the small trusted core responsible for fundamental system mechanisms and resources.

System space

The domain in which Flint's operating-system services execute.

System-space processes are not part of the kernel. They are isolated processes that provide functionality such as filesystem services, device drivers, networking, and system supervision.

System-space processes receive the capabilities necessary to perform their responsibilities.

User space

The domain in which ordinary user applications execute.

User-space processes generally have fewer capabilities than system-space services and interact with the system through the interfaces provided by the kernel and system-space services.

Relationship

The three domains should be understood as:

Kernel space
    │
    │ provides mechanisms and resources
    ▼
System space
    │
    │ provides system services
    ▼
User space
    │
    │ runs applications
    ▼
User

"System space" is a Flint architectural term. It does not imply a separate CPU privilege level or hardware-enforced execution mode.

Core philosophy

Flint should be small and secure by design

The privileged kernel should contain the minimum functionality necessary to provide fundamental operating-system mechanisms. Higher-level functionality should be moved to userspace whenever practical.

Security and isolation should come from the architecture itself rather than relying primarily on conventions and the correctness of every individual component.

Core principles:

• Minimize privileged code.
• Prefer userspace over kernel space when practical.
• Isolate components from one another.
• Use explicit IPC for communication.
• Grant authority explicitly through capabilities.
• Keep security-critical mechanisms small and auditable.
• Do not introduce complexity without a clear benefit.

Goal: A small trusted computing base with strong isolation between components.

Architecture

Flint will use a microkernel architecture. The kernel will contain only core mechanisms that require privileged execution, while higher-level operating-system services will run in userspace and communicate with the kernel and each other through IPC.

The kernel will primarily provide mechanisms such as:

• Process and thread management
• Scheduling
• Memory and address-space management
• IPC
• Interrupt handling
• Timers

Higher-level services such as filesystems, device drivers, networking, and similar components should run in userspace where practical.

Principle: Keep the privileged kernel small; move policy and higher-level services into userspace.

Modularity

Flint's kernel will be composed of modular components with clearly defined interfaces.

Components such as the scheduler, memory manager, IPC subsystem, and interrupt handling should be independently structured rather than tightly coupled into a single implementation.

Modularity refers to separation of responsibilities and interfaces; it does not necessarily imply that components must be dynamically loadable at runtime.

Principle: Components should communicate through well-defined interfaces and minimize unnecessary dependencies on each other's implementation details.

Multitasking

Flint will use preemptive multitasking. The kernel's scheduler can interrupt a running task and switch execution to another task, preventing a task from monopolizing the CPU.

A timer interrupt will provide the mechanism for periodically preempting the currently running task.

Principle: No userspace task should be able to prevent other tasks from receiving CPU time simply by refusing to yield.

Symmetric multiprocessing

SMP will be omitted from early versions of Flint. The initial kernel will target a single CPU core/hart.

The architecture should avoid unnecessarily preventing future SMP support, but synchronization and other SMP-specific mechanisms will only be introduced when SMP becomes a requirement.

Principle: Keep initial implementation simple without deliberately making future SMP support impossible.

Memory allocation

Memory-management functionality should be kept in the kernel only when it requires privileged access or must enforce system-wide invariants.

Higher-level allocation mechanisms should be implemented in userspace where practical. For example, userspace should provide its own heap allocator rather than relying on a kernel-level malloc.

The kernel should provide the primitives required for userspace to obtain, map, and manage memory safely.

Device drivers

Device drivers should run in userspace whenever they can do so safely and reasonably.

Drivers may run in the kernel when they require privileged access, cannot be reasonably implemented in userspace, or when placing them in the kernel is necessary for correctness or practical performance.

Principle: Prefer userspace, but do not force functionality out of the kernel when doing so would be unreasonable.

Inter-process communication

Flint will use message-oriented IPC as the primary mechanism for communication between processes and userspace services.

Processes should not directly access each other's memory. Communication should instead occur through explicit messages mediated by the kernel.

This provides strong process isolation and makes communication between components explicit and controllable.

Shared memory may be introduced later for cases where message passing alone is impractical, such as transferring large amounts of data, but it should not be the default communication mechanism.

Principle: Prefer explicit, kernel-mediated communication over shared mutable state.

Security model

Flint will use a capability-based security model.

Processes will access resources through explicit capabilities granted by the kernel. Possession of a capability determines what a process is authorized to access or perform.

Processes should not receive unrestricted access to system resources by default.

Capabilities should be unforgeable and managed by the kernel, preventing userspace processes from gaining access to resources they have not been granted.

Principle: Authority should be explicit, minimal, and granted by the kernel.

System call interface

Flint will expose a small call interface focused on fundamental kernel mechanisms.

System calls should provide primitives such as process management, memory management, IPC, capability management, and synchronization rather than high-level operating-system functionality.

Higher-level functionality should be implemented by userspace services.

Principle: the kernel provides mechanisms; userspace provides policy.

Unsafe code

Flint should minimize the use of unsafe code. Unsafe code should be confined to the lowest-level portions of the system where interaction with hardware, architecture-specific mechanisms, or other inherently unsafe operation requires it.

Higher-level kernel code should remain safe Rust whenever practical.

Unsafe abstractions should expose safe interfaces to the rest of the kernel, with their safety invariants clearly documented.

Principle: Keep unsafe code small, isolated and auditable.

Fault isolation

Failures in userspace services should not inherently bring down the kernel or unrelated services.

Userspace services such as drivers, filesystems, and networking components should be designed to be independently restartable where practical.

The kernel should maintain enough isolation that a userspace service failure cannot directly corrupt the kernel or arbitrarily compromise unrelated processes.

Principle: A component failure should affect the smalles possible part of the system.

Userspace initialization

After kernel initialization, Flint will create an initial userspace process running /bin/uinit.

uinit will act as the initial userspace supervisor. It will initialize the userspace environment, start system services, establish their IPC relationships and capabilities, and manage their lifecycle.

The kernel will provide the mechanisms required to create and isolate the initial process, but userspace initialization policy will remain the responsibility of uinit.

Principle: Once the kernel has established the minimum environment required for userspace, initialization and service management should be delegated to userspace.