10.1 Introduction : au-delà du kernel généraliste

Les systèmes d’exploitation généralistes (Linux, Windows, macOS) ont été conçus pour l’équité et l’universalité : servir simultanément un navigateur web, un compilateur, un serveur de base de données et un lecteur vidéo. Cette universalité a un coût structurel : des couches d’abstraction empilées au fil des décennies (chroot → namespaces → cgroups → containers → orchestrateurs) qui ajoutent de la latence, de la complexité et des copies mémoire inutiles.

LplKernel adopte une philosophie inverse : le noyau ne sert qu’à un seul objectif, orchestrer un moteur VR/FullDive déterministe client-serveur. Cette spécialisation radicale ouvre la porte à des innovations architecturales impossibles sur un OS généraliste. Ce chapitre explore les axes de rupture qui constitueront les fondations des phases avancées du noyau.¹

10.2 L’interface Zero-Syscall : ring-buffers asynchrones

10.2.1 Le coût caché du changement de contexte

Dans un OS classique, chaque interaction application → noyau (lecture fichier, envoi réseau, allocation mémoire) transite par un appel système (INT 0x80, SYSENTER, SYSCALL). Ce mécanisme force un changement de contexte : vidage des pipelines d’exécution du CPU, transition Ring 3 → Ring 0, pollution du cache L1/L2 d’instructions. Sur une architecture x86 moderne, un syscall simple coûte entre 100 et 400 cycles CPU, inacceptable quand le budget de frame est de 11 ms (90 Hz).¹

Le piège mortel de SWAPGS

Lors de l’utilisation de l’instruction SYSCALL (très rapide), le processeur passe en Ring 0 sans changer la pile (RSP pointe toujours vers la pile utilisateur). Le noyau doit exécuter SWAPGS pour basculer le registre GS vers la structure interne du CPU (MSR_KERNEL_GS_BASE) afin d’accéder à la pile noyau sécurisée. Sauf que si une interruption matérielle (NMI ou IRQ timer) survient alors que le processeur est déjà en Ring 0, le handler d’interruption ne doit surtout pas exécuter aveuglément SWAPGS : cela inverserait le registre GS vers l’espace utilisateur, ce qui provoquerait un crash absolu (Double Fault) au moindre accès mémoire suivant. C’est l’un des bugs les plus subtils et destructeurs en OSDev.

10.2.2 Le modèle Submission/Completion Queue

LplKernel supprime les syscalls bloquants en généralisant le paradigme de io_uring (Linux 5.1+) à toutes les interactions kernel-userspace :

1. L’espace utilisateur et le noyau partagent une zone de mémoire contenant deux anneaux circulaires (ring buffers) : une Submission Queue (SQ) et une Completion Queue (CQ).
2. Quand un processus veut interagir avec le matériel, il poste la requête dans la SQ sans aucune interruption ni changement de Ring.
3. Un ou plusieurs threads noyau dédiés, exécutés sur des cœurs SMP distincts, pollent la SQ à la vitesse de la RAM, exécutent la demande et déposent le résultat dans la CQ.
4. Le processus consulte la CQ de manière asynchrone lorsqu’il est prêt.

Résultat : zéro changement de contexte, zéro interruption du thread applicatif. Le pipeline d’instructions CPU n’est jamais vidé. Le cache L1 reste chaud. C’est le Graal absolu pour la simulation temps réel : le thread de rendu VR en Ring 3 n’est jamais interrompu.

L’infrastructure existante de LplKernel (Ring Buffer SPSC client, SMP multi-cœur, APIC/IPI) forme les briques de base de cette architecture. Le Ring Buffer 32 B / 32 entrées implémenté en Phase 4 en est le prototype fonctionnel.

10.3 Single Address Space OS (SASOS) et sécurité par capacités

10.3.1 Le paradigme classique et ses limites

Dans un OS traditionnel, chaque processus possède son propre espace d’adressage virtuel, isolé par des tables de pages séparées. Tout changement de contexte entre processus force un vidage du TLB (Translation Lookaside Buffer), ce qui détruit les traductions virt→phys cachées et provoque une avalanche de cache misses.

10.3.2 L’espace d’adressage unique

En mode 64-bit (objectif Phase 10), LplKernel peut adopter le modèle SASOS (Single Address Space Operating System), popularisé par le projet de recherche Theseus OS. Dans ce paradigme, tous les processus, y compris le noyau, partagent le même espace d’adressage virtuel de 128 To ($2^{47}$ octets en x86-64 canonical addressing).

L’isolation ne se fait plus par des tables de pages séparées, mais par l’isolation intra-linguistique (comme la sémantique de possession en Rust ou les std::unique_ptr stricts en C++) doublée d’une protection matérielle de nouvelle génération : les Memory Protection Keys (PKeys ou PKU) intégrées aux processeurs Intel depuis Skylake.

Chaque page (PTE) est étiquetée avec une clé de protection (4 bits, soit 16 domaines d’isolation matérielle). Le registre 32-bits PKRU (Protection Key Rights for User pages) dicte les droits de lecture/écriture pour chacune de ces 16 clés. La force de cette technologie tient à ce que le registre PKRU peut être modifié depuis l’espace utilisateur via l’instruction WRPKRU en seulement 2 cycles CPU, de façon parfaitement synchrone et sans aucun flush du TLB.

10.3.3 Sécurité par capacités

La sécurité n’est plus gérée par des droits utilisateur UNIX (UID/GID, chmod), mais par des capacités : des tokens cryptographiques locaux forgés par le noyau. Si une application détient la capacité (un pointeur authentifié) vers un fichier, un device réseau ou une zone mémoire, elle a le droit de l’utiliser. C’est le principe du Zero Trust appliqué au niveau du processeur, ce qui élimine toute la surface d’attaque liée à l’escalade de privilèges traditionnelle.

10.4 Auto-resizing natif et Time-Travel RAM

10.4.1 Redimensionnement à chaud

Les solutions de conteneurisation actuelles (Docker, Kubernetes) s’appuient sur l’OS hôte pour la gestion des ressources, ajoutant des couches d’abstraction coûteuses. LplKernel intègre le redimensionnement natif directement dans le noyau :

• Demand Paging (Lazy Allocation) : le noyau alloue les pages physiques uniquement lors d’un Page Fault, quand le processus accède réellement à l’adresse. La mémoire promise mais non touchée ne consomme aucune RAM physique.
• Ballooning Natif : Lorsque le système détecte une pression mémoire (seuil de free_pages trop bas), le noyau peut demander à ses propres processus de libérer des pages non critiques ou de compresser la mémoire en ligne (zswap natif), augmentant la capacité effective sans interaction externe.
• Zero-Copy Resizing : en contrôlant directement les tables de pages, le noyau déplace des blocs de données entre processus sans copie mémoire : une simple manipulation des entrées PDE/PTE. Les données ne bougent pas physiquement, seul le mapping change.

10.4.2 Time-Travel RAM : Git pour la mémoire vive

Le Copy-On-Write (COW), déjà utilisé par fork() sous UNIX, est poussé à l’extrême dans LplKernel pour offrir un versioning natif de la mémoire :

• Snapshot instantané : le noyau « photographie » l’état RAM d’un processus en 0 ms. Il suffit de marquer toutes les pages en lecture seule et d’incrémenter le compteur de référence dans le PMM ; aucune copie n’est effectuée.
• Instant Rollback : si un processus crashe, le noyau le ramène à son état d’il y a $n$ secondes en restaurant le mapping snapshot. C’est la fondation du Rollback Netcode (Chapitre 6) appliquée au niveau mémoire.
• Fork instantané : dupliquer un processus lourd (par exemple un modèle IA local qui a chargé ses poids en VRAM) en partageant la même RAM physique en lecture seule, jusqu’à ce qu’un des forks modifie une page, alors copiée à la demande.

10.5 Ordonnanceur EDF : garanties temporelles absolues

10.5.1 Limites du Round-Robin

L’ordonnancement Round-Robin classique distribue le temps CPU de manière « équitable » : chaque tâche reçoit un quantum de temps identique. Cette équité est incompatible avec les systèmes temps réel : une tâche de rendu VR qui rate son deadline de 2 ms provoque une frame perdue et un malaise vestibulaire chez l’utilisateur.

10.5.2 Earliest Deadline First (EDF)

L’ordonnanceur EDF (Earliest Deadline First) remplace la notion de priorité statique par une garantie temporelle contractuelle. Chaque tâche déclare un SLA (Service Level Agreement) de la forme :

$\text{« J'ai besoin de } C \text{ ms de CPU pur d'ici les } T \text{ prochaines ms. »}$

Par exemple : « Le thread de rendu VR a besoin de 2 ms toutes les 11 ms » (90 Hz). Le noyau vérifie mathématiquement la faisabilité via le test de Liu & Layland :

$U = \sum_{i=1}^{n} \frac{C_i}{T_i} \leq 1$

où $U$ est l’utilisation CPU totale, $C_i$ le temps d’exécution pire cas de la tâche $i$, et $T_i$ sa période. Si $U \leq 1$, le système est ordonnançable : toutes les deadlines seront respectées, mathématiquement garanti.

L’EDF est optimal pour les systèmes uniprocesseur : il peut ordonnancer tout ensemble de tâches pour lequel un ordonnancement valide existe. Sur SMP, des extensions comme le Global-EDF ou le Partitioned-EDF (affectation par cœur) complètent le modèle.

10.6 Data Plane Network : bypass TCP/IP et Zero-Copy DMA

10.6.1 Le problème de la pile réseau classique

Dans un OS standard, un paquet réseau entrant suit un chemin tortueux : la carte réseau (NIC) écrit dans un buffer DMA du noyau → le noyau copie les données dans un buffer de socket → l’application copie depuis le socket vers son propre buffer. Chaque étape implique une copie mémoire et un changement de contexte. Pour la communication inter-conteneurs sur le même hôte, cette pile traversée est particulièrement absurde.

10.6.2 Le bypass natif

LplKernel configure la NIC pour qu’elle transfère les paquets via DMA directement dans la RAM de l’application utilisateur (ici, le serveur Flakkari), en utilisant RSS (Receive Side Scaling) pour distribuer le trafic matériellement par file de réception :

1. L’application demande au noyau de mapper le RX Ring de la NIC dans son espace d’adressage.
2. Le noyau configure les descripteurs DMA de la NIC pour écrire dans ces pages utilisateur (épinglées via kernel_pinned_alloc).
3. Aucun traitement de paquet par le noyau. La pile TCP/IP classique est contournée.
4. Pour la communication intra-hôte (deux conteneurs sur la même machine), le noyau remplace la pile réseau par un Shared Memory Ring transparent pour l’application, avec des latences de l’ordre de la nanoseconde.

10.6.3 Réseau Zero-Copy pour le FullDive

Pour le rendu VR distant ou l’IA distribuée, le chemin optimal est NIC → DMA → RAM applicative → GPU. LplKernel peut mapper la mémoire DMA de la NIC directement dans l’espace d’adressage accessible au GPU (via les pages épinglées CDMM, cf. Chapitre 2), ce qui crée un pipeline NIC → GPU sans aucune copie CPU intermédiaire.

10.7 Multiplexage matériel GPU/NPU natif

L’assignation de matériel spécialisé (GPU, NPU, TPU) à des processus isolés est un problème non résolu par les OS actuels. Les solutions existantes sont soit monolithiques (passthrough PCIe complet) soit propriétaires (NVIDIA vGPU).

LplKernel aborde le problème nativement : le noyau abstrait les accélérateurs matériels et les expose comme une ressource fluide, au même titre que la RAM ou le temps CPU. Un processus peut demander : « alloue-moi 15 % de la puissance de calcul tensoriel ». Le noyau multiplexe les accès au matériel en temps réel, de manière agnostique vis-à-vis du constructeur.

Cette approche repose sur le GPU System Processor (GSP), le processeur RISC-V intégré dans les GPU NVIDIA depuis l’architecture Turing (cf. Chapitre 5), programmable pour arbitrer les contextes GPU sans intervention CPU.

10.8 Observabilité Zero-Cost

Les solutions de monitoring actuelles (Prometheus, Datadog) consomment un pourcentage significatif de CPU pour l’instrumentation. LplKernel intègre une API d’observabilité directement dans l’ordonnanceur et le gestionnaire mémoire :

• Des buffers circulaires lock-free en espace utilisateur (Ring Buffers SPSC, cf. Chapitre 2) reçoivent les événements d’instrumentation sans aucun changement de contexte.
• Le noyau écrit les métriques (allocations, ticks, interruptions, latences) à la vitesse de la RAM, sans write() syscall.
• L’agent de monitoring lit ces buffers à son rythme, en mode asynchrone.

Le coût mesuré de cette instrumentation est strictement borné à la vitesse d’une écriture mémoire séquentielle, essentiellement 0 % de CPU supplémentaire par rapport à un noyau non instrumenté.

10.9 La convergence kernel-engine : LplPlugin → LplKernel

10.9.1 La vision unifiée

LplPlugin (le moteur/engine côté espace utilisateur) et LplKernel sont conçus pour converger progressivement. L’objectif final est que le moteur soit compilé comme une librairie kernel-adjacent (similaire à libc/libk), intégrée directement dans le noyau, ce qui élimine la frontière user/kernel pour les chemins critiques.

Cette convergence suit une feuille de route en 5 phases unifiées :

10.9.2 Matrice de dépendances croisées

Les deux projets se nourrissent mutuellement :

• Kernel → Plugin : politique de timer/interruption déterministe, garanties mémoire pour les sections de boucle déterministe, interfaces réseau/driver bas-niveau.
• Plugin → Kernel : contrats runtime (cadence de tick, flux de données, contraintes de réconciliation), exigences mesurées de latence et débit qui alimentent les priorités kernel, priorités de migration pour la réduction de dépendances.

10.9.3 KPIs de suivi continu

10.10 Diagramme d’architecture complet

L’architecture fusionnée de LplKernel est représentée ci-dessous. Les composants sont codés par couleur :

• Bleu : Kernel Core (fondations Phases 1-5)
• Violet : Innovation Native (vision long terme)
• Vert : Espace Utilisateur
• Noir : Hardware
• Orange : Interface asynchrone

flowchart TD
    %% ================= STYLES =================
    classDef hardware fill:#2d3436,stroke:#b2bec3,stroke-width:2px,color:#dfe6e9;
    classDef kernel_core fill:#0984e3,stroke:#74b9ff,stroke-width:2px,color:#fff;
    classDef innovation fill:#6c5ce7,stroke:#a29bfe,stroke-width:3px,color:#fff;
    classDef userspace fill:#00b894,stroke:#55efc4,stroke-width:2px,color:#fff;
    classDef interface fill:#e17055,stroke:#fab1a0,stroke-width:2px,color:#fff;

    %% ================= USERSPACE =================
    subgraph Userspace ["User Space (Single Address Space - SASOS)"]
        direction LR
        App1["🎮 VR Engine / Rendering
(PKey: 0x1)"]:::userspace
        App2["🌐 Flakkari Server
(PKey: 0x2)"]:::userspace
        App3["🧠 Distributed AI Model
(PKey: 0x3)"]:::userspace
    end

    %% ================= INTERFACE =================
    subgraph Interface ["Asynchronous Kernel-User Boundary (Zero Context-Switch)"]
        direction LR
        RB_Net["Network Ring-Buffer
(Submission/Completion)"]:::interface
        RB_Sys["System Ring-Buffer
(Memory, I/O, IPC)"]:::interface
    end

    %% ================= KERNEL SPACE =================
    subgraph Kernel ["LplKernel Space (Ring 0)"]
        direction TB

        subgraph Boot_Init ["Boot & CPU Init (Phase 1-3)"]
            direction LR
            Boot["GRUB / Multiboot
Higher-Half Boot"]:::kernel_core
            Protect["GDT & TSS
Ring 0 / Ring 3"]:::kernel_core
            Intr["IDT & Exceptions
(#PF, #GP, #DF)"]:::kernel_core
            SMPInit["AP Trampoline
INIT/SIPI Dispatch"]:::kernel_core
        end

        subgraph Sched ["Scheduling & Topology (Phase 6+)"]
            direction LR
            EDF["⏱️ Scheduler EDF
(Earliest Deadline First)
Hard Real-Time Guarantees"]:::innovation
            SMP["Multi-Core SMP Manager
CPU Affinity & NUMA Policy"]:::kernel_core
            IPC["Zero-Copy IPC Router
Native Shared Memory"]:::innovation
        end

        subgraph Mem ["Memory Subsystem (Phase 4+)"]
            direction LR
            SASOS["VMM SASOS
Capability-Based Isolation (PKeys)"]:::innovation
            VMM["Classic VMM
Virt->Phys, Page Tables"]:::kernel_core
            PMM["PMM & Allocators
Buddy, Slab, Frame Arena, Pools"]:::kernel_core
            AutoResize["🎈 Native Auto-Resizing
Ballooning & Lazy Alloc"]:::innovation
            Snapshot["📸 Time-Travel RAM
Insta-Fork / Copy-On-Write"]:::innovation
        end

        subgraph Drivers ["Drivers & I/O (Phase 5+)"]
            direction LR
            StandardDrv["Base Drivers
PS/2, Serial, VGA, ATA"]:::kernel_core
            GPUMux["💻 HW Multiplexer
GPU/NPU Partitioning"]:::innovation
            NetBypass["⚡ Network Data Plane
TCP/IP Stack Bypass"]:::innovation
            Observability["👁️ Zero-Cost Telemetry
Circular Buffers"]:::innovation
        end

        %% Internal Kernel Routing
        Boot --> Protect --> Intr --> SMPInit
        Intr -.->|#PF Page Fault| Mem
        Intr -.->|Interrupts| Drivers
        Sched <-->|Task Management| Mem
        Sched <-->|Asynchronous Syscalls| Drivers
    end

    %% ================= HARDWARE =================
    subgraph Hardware ["Hardware Layer"]
        direction LR
        CPU["CPU x86_64
(LAPIC, x2APIC, MMU)"]:::hardware
        RAM["Physical Memory
(NUMA Nodes)"]:::hardware
        IO_Ctrls["Controllers
(IOAPIC, PIT, RTC)"]:::hardware
        Storage["Storage
(ATA PIO, NVMe)"]:::hardware
        NIC["Network Card
(NIC with RSS)"]:::hardware
        GPU["Accelerators
(GPU / NPU)"]:::hardware
    end

    %% ================= EXTERNAL CONNECTIONS =================

    %% Userspace <--> Interface
    App1 <-->|Asynchronous Sys Operations| RB_Sys
    App2 <-->|Tx/Rx Packets| RB_Net
    App3 <-->|IPC/Sys Calls| RB_Sys

    %% Interface <--> Kernel
    RB_Sys <-->|Polling by dedicated Kernel Threads| Sched
    RB_Net <-->|Direct queue routing| NetBypass

    %% Kernel <--> Hardware
    SMP -->|Execution & IPI| CPU
    PMM -->|RAM Read/Write| RAM
    StandardDrv -->|IRQ / EOI / DMA| IO_Ctrls
    StandardDrv -->|PIO / DMA| Storage
    NetBypass -->|MAC/PHY Configuration| NIC
    GPUMux -->|PCIe Commands| GPU
    IO_Ctrls -->|"Timer Ticks (APIC/PIT)"| EDF

    %% ================= THE MAGIC: HARDWARE BYPASS =================
    %% These links represent the Zero-Copy / Direct Access Bypass innovations
    NIC =====|"⚡ Direct Zero-Copy DMA RX/TX (Bypass)"| App2
    GPU =====|"⚡ Direct Partitioned Mapping (Bypass)"| App1
    GPU =====|"⚡ Direct Partitioned Mapping (Bypass)"| App3
    RAM =====|"⚡ Direct access via PKeys (SASOS)"| Userspace

10.11 Synthèse

L’architecture visionnaire de LplKernel redéfinit la relation entre matériel et application. Le noyau n’est plus un intermédiaire lourd mais un orchestrateur d’accès direct :

La conteneurisation actuelle s’est construite par-dessus des concepts des années 1990 (chroot, namespaces). Penser ces problématiques dès les fondations d’un nouveau système change la donne, et c’est exactement ce que LplKernel accomplit.

Notes de bas de page du chapitre 10

ANNEXES