return to index

§ L4RE ARCH

┌─────────────┐  ┌─────────────┐  ┌─────────────┐      
│ APPLICATION │  │ APPLICATION │  │ APPLICATION │ USER APPS.
└─────────────┘  └─────────────┘  └─────────────┘      
                                                  
┌──────────────┐ ┌─────────────┐  ┌────────────┐  
│FILE SYSTEMS  │ │ NETWORKING, │  │ MEMORY     │  KERN COMPONENTS
│VFS / FS IMPL.│ │ SOCKETS,    │  │ MANAGEMENT │  SHIFTED TO USER
│              │ │ PROTOCOLS   │  │            │  SPACE
└──────────────┘ └─────────────┘  │ PAGE ALOC. │  
┌──────────────────────────────┐  │ SWAPPING   │  SERVICES
│DEVICE DRIVERS                │  │            │  
└──────────────────────────────┘  └────────────┘  
                                                  USER MODE
───────────────────────────────────────────────────────────────────
                                                  KERN MODE
┌──────────────────────────────────────────────┐    
│                                              │   
│  ┌──────────────────────┬──────────────────┐ │    
│  │ SYSCALL INTERFACE    │ ADDRESS SPACE,   │ │  A MINIMAL KERN.
│  ├──────────────────────┤ THREADS,IPC,     │ │    
│  │ HARDWARE ACCESS      │ SCHEDULING       │ │    
│  └──────────────────────┴──────────────────┘ │    
│                                              │    
│ Microkernel                                  │    
└──────────────────────────────────────────────┘    
                                                       
................................................
                                                               
┌───────────────────────────────────────────────┐    
│   HARDWARE CPU, MEMORY, PCI, DEVICES ....     │    
└───────────────────────────────────────────────┘    

            Fig.1 L4 microkernel architecture

                                                                        
Slide 8, "Microkernel-based Operating Systems - Interoduction"      
Jan Bierbaum and Carsten Weinhold, TU Dresden, 15.Okt.2024          

§ OBJECTS AND CAPABILITIES

Everything is an object (S.24 of ¹): Task, Thread, IPC Gate, IRQ, Factory…

Tasks hold references to kernel objects in their respective Object space, which is a kernel-protected table. These references are called capabilities. ²

Kernel (or services) exposes handles (objects) to tasks, restrained in their task-local capability space. In other words, the capability space is is the task name space of the system objects. The task can only invoke system functions via the objects assigned (mapped) to them. The object (capability) name space is configured by the task’s creator. (some sort of tree-hierarchy)

┌────────┐                                              ┌───────────┐
│ CLIENT │                                              │ SERVICE 1 │
└────┬───┘                                              └──────▲────┘
     │invoke(capability(3))                                    │     
     │    ┌───────────────────────────────────────────────┐    │     
     │    │   ┌───┐                                       │    │     
     │    │   │ 1 │                                       │    │     
     │    │   ├───┤           ┌────────────────────────┐  │    │     
     │    │   │ 2 │           │IPC GATE: COMM. CHANNEL │  │    │     
     │    │   ├───┤           │          FOR SERVICE 1 │  │    │     
     └────┼──►│ 3 ├──────────►│                        ├──┼────┘     
          │   ├───┤           └────────────────────────┘  │          
          │   │ 4 │                                       │          
          │   └───┘                                       │          
          │   TASK CAPS TABLE            KERNEL           │          
          └───────────────────────────────────────────────┘          

            Fig.2 Client - Service communication via task cap

                                                                         
        ┌──────┐      ┌────────┐               ┌───────────────┐           
        │      │ IRQ  │        │invoke_object  │ USER SPACE    │           
        │DEVICE├──────► KERNEL ├───────────────► DEVICE DRIVER │           
        │      │      │        │(irq_cap,...)  │               │           
        └──────┘      └────────┘               └───────────────┘           
                                                                             
            Fig.3 IRQ handling with user space device driver


Slide 29 and 34, "Microkernel-based Operating Systems - Interoduction"
Jan Bierbaum and Carsten Weinhold, TU Dresden, 15.Okt.2024  

§ TASK, THREAD, ADDRESS SPACE

§ COMMUNICATION: IPC GATE (WIP)

Some basic facts about L4 IPC

• is always synchronous ³
• invokes a subroutine in a different context (context switch?)
• provides the only (non-debugging) way of syscalls

UTCB (User-level Thread Control Block)

• Message Registers (syscall params)
• Buffer Registers (flexpage)
• Thread Control Registers (thread-private data …)

§ BASIC USERMODE L4RE COMPONENTS (pkg/l4re-core/)

• User-level libraries: uClibC, libstdc++, IPC client/server framework …
• Task loader: Ned (init process)
• Basic Resource Manager: Moe (root task, provides various abstractions). Sigma0 (memory management)

§ acronyms and things

L4RE

• L4RE: L4 Runtime Environment
• UTCB : user-level control block
• recursive address spaces, flexpage

NOVA concepts

• Protection Domain (PD) ~= Task : {objet, memory, I/O}
• Execution Context (EC) ~= Thread : entity that executes code (user / kernel); Belongs to exactly one PD and not migratable (pinned on cpu)
• Scueduling Context (SC) : SC supplies EC with time.
• Portal (PT) ~= IPC Gate, Endpoint for syncronous IPC
• IRQ interrupts represented as semaphores (NOVA)