Introducing kernel-agnostic Genode executables Norman Feske < - - PowerPoint PPT Presentation

introducing kernel agnostic genode executables
SMART_READER_LITE
LIVE PREVIEW

Introducing kernel-agnostic Genode executables Norman Feske < - - PowerPoint PPT Presentation

Introducing kernel-agnostic Genode executables Norman Feske < norman.feske@genode-labs.com > Outline 1. Kernel diversity - Whats the appeal? 2. Bridging the gap between kernels Notion of components Raising the level of abstraction of


slide-1
SLIDE 1

Introducing kernel-agnostic Genode executables

Norman Feske <norman.feske@genode-labs.com>

slide-2
SLIDE 2

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 2

slide-3
SLIDE 3

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 3

slide-4
SLIDE 4

Despair-driven development

Introducing kernel-agnostic Genode executables 4

slide-5
SLIDE 5

Despair-driven development

2003: Security came into focus of the L4 community Capability-based security → new kernel generation Genode started as the designated user land of NOVA

Introducing kernel-agnostic Genode executables 4

slide-6
SLIDE 6

Despair-driven development

2003: Security came into focus of the L4 community Capability-based security → new kernel generation Genode started as the designated user land of NOVA Problem: NOVA did not exist How to build a user land for a non-existing kernel? Planning in terms of interim solutions Weak assumptions about the kernel

Introducing kernel-agnostic Genode executables 4

slide-7
SLIDE 7

Despair-driven development

2003: Security came into focus of the L4 community Capability-based security → new kernel generation Genode started as the designated user land of NOVA Problem: NOVA did not exist How to build a user land for a non-existing kernel? Planning in terms of interim solutions Weak assumptions about the kernel Approach: Target two existing kernels at once Opposite ends of a spectrum: Linux and L4/Fiasco If it works on those, it should be portable to NOVA

Introducing kernel-agnostic Genode executables 4

slide-8
SLIDE 8

Reassuring experiences

Introducing kernel-agnostic Genode executables 5

slide-9
SLIDE 9

Reassuring experiences

Boosting our development

◮ Quick development-test cycle on GNU/Linux ◮ Debugging via GDB, strace ◮ Kernel debugger on L4/Fiasco Introducing kernel-agnostic Genode executables 5

slide-10
SLIDE 10

Reassuring experiences

Boosting our development

◮ Quick development-test cycle on GNU/Linux ◮ Debugging via GDB, strace ◮ Kernel debugger on L4/Fiasco

Stressing the robustness of our code Different kernels expose subtle problems

Introducing kernel-agnostic Genode executables 5

slide-11
SLIDE 11

Reassuring experiences

Boosting our development

◮ Quick development-test cycle on GNU/Linux ◮ Debugging via GDB, strace ◮ Kernel debugger on L4/Fiasco

Stressing the robustness of our code Different kernels expose subtle problems Cross-correlating bugs and performance problems

Introducing kernel-agnostic Genode executables 5

slide-12
SLIDE 12

Reassuring experiences

Boosting our development

◮ Quick development-test cycle on GNU/Linux ◮ Debugging via GDB, strace ◮ Kernel debugger on L4/Fiasco

Stressing the robustness of our code Different kernels expose subtle problems Cross-correlating bugs and performance problems Getting clarity of application-level requirements

Introducing kernel-agnostic Genode executables 5

slide-13
SLIDE 13

Benefiting from a high diversity of kernels

Kernels differ in many respects: Hardware-platform support Leveraged hardware features Virtualization, IOMMU, SMP, TrustZone Performance, security, scheduling Implementation, License Community

Introducing kernel-agnostic Genode executables 6

slide-14
SLIDE 14

Maintenance burden

Surprisingly little kernel-specific code!

Repository Source lines of code repos/ 254,367 repos/base/ 23,282 repos/base-fiasco/ 1,563 repos/base-foc/ 3,264 repos/base-linux/ 3,582 repos/base-nova/ 5,711 repos/base-okl4/ 1,958 repos/base-pistachio/ 1,869 repos/base-sel4/ 3,300 repos/base-hw/ 14,751

→ manageable

Introducing kernel-agnostic Genode executables 7

slide-15
SLIDE 15

Emergence of a vision

What POSIX is for monolithic OSes, Genode may become for microkernel-based OSes. → Deliberate cultivation of cross-kernel interoperability

Introducing kernel-agnostic Genode executables 8

slide-16
SLIDE 16

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 9

slide-17
SLIDE 17

Overcoming prevalent assumptions

Introducing kernel-agnostic Genode executables 10

slide-18
SLIDE 18

Overcoming prevalent assumptions

Application requirements are rather mysterious Preoccupation with scalability and performance concerns POSIX (?) Thread-local storage (?)

Introducing kernel-agnostic Genode executables 10

slide-19
SLIDE 19

Overcoming prevalent assumptions

Application requirements are rather mysterious Preoccupation with scalability and performance concerns POSIX (?) Thread-local storage (?) We disregarded those premises (liberating!)

Introducing kernel-agnostic Genode executables 10

slide-20
SLIDE 20

Overcoming prevalent assumptions

Application requirements are rather mysterious Preoccupation with scalability and performance concerns POSIX (?) Thread-local storage (?) We disregarded those premises (liberating!) ...to be considered later.

Introducing kernel-agnostic Genode executables 10

slide-21
SLIDE 21

Holistic architecture

Clean-slate design

Introducing kernel-agnostic Genode executables 11

slide-22
SLIDE 22

Hiding the construction of components

Traditional: Tight user-kernel interplay

Introducing kernel-agnostic Genode executables 12

slide-23
SLIDE 23

Hiding the construction of components

Traditional: Tight user-kernel interplay Interesting at application level: Defining the executable to load → ROM dataspace Exercising control over the new protection domain → Parent-child RPC interface

Introducing kernel-agnostic Genode executables 12

slide-24
SLIDE 24

Hiding the construction of components

Traditional: Tight user-kernel interplay Interesting at application level: Defining the executable to load → ROM dataspace Exercising control over the new protection domain → Parent-child RPC interface Approach: Satisfy those requirements, hide “loading” mechanics

Introducing kernel-agnostic Genode executables 12

slide-25
SLIDE 25

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 13

slide-26
SLIDE 26

Traditional: IPC involves kernel details

Microkernel IPC ridden with technicalities and jargon thread IDs, task IDs, portals, message registers, message tags, message dopes, message-buffer layouts, UTCBs, MTDs, hot spots, CRDs, receive windows, badges, reply capabilities, flex pages, string items, timeouts, short IPC vs. long IPC

Introducing kernel-agnostic Genode executables 14

slide-27
SLIDE 27

Traditional: IPC involves kernel details

Microkernel IPC ridden with technicalities and jargon thread IDs, task IDs, portals, message registers, message tags, message dopes, message-buffer layouts, UTCBs, MTDs, hot spots, CRDs, receive windows, badges, reply capabilities, flex pages, string items, timeouts, short IPC vs. long IPC IDL compilers supposedly hide those details.

Introducing kernel-agnostic Genode executables 14

slide-28
SLIDE 28

Traditional: IPC involves kernel details

Microkernel IPC ridden with technicalities and jargon thread IDs, task IDs, portals, message registers, message tags, message dopes, message-buffer layouts, UTCBs, MTDs, hot spots, CRDs, receive windows, badges, reply capabilities, flex pages, string items, timeouts, short IPC vs. long IPC IDL compilers supposedly hide those details. But they don’t.

Introducing kernel-agnostic Genode executables 14

slide-29
SLIDE 29

IPC from the application’s perspective

Introducing kernel-agnostic Genode executables 15

slide-30
SLIDE 30

IPC from the application’s perspective

Genode’s API level: Consistent and simple nomenclature (client, server, session, RPC object, capability) Synchronous RPC in the strictest sense (RPC stub code generated by C++ templates, no IDL)

Introducing kernel-agnostic Genode executables 15

slide-31
SLIDE 31

IPC from the application’s perspective

Genode’s API level: Consistent and simple nomenclature (client, server, session, RPC object, capability) Synchronous RPC in the strictest sense (RPC stub code generated by C++ templates, no IDL) Capabilities instead of global name spaces (lifetime managed as C++ smart pointer)

Introducing kernel-agnostic Genode executables 15

slide-32
SLIDE 32

IPC from the application’s perspective

Genode’s API level: Consistent and simple nomenclature (client, server, session, RPC object, capability) Synchronous RPC in the strictest sense (RPC stub code generated by C++ templates, no IDL) Capabilities instead of global name spaces (lifetime managed as C++ smart pointer) Asynchronous notifications without payload (like interrupts)

Introducing kernel-agnostic Genode executables 15

slide-33
SLIDE 33

IPC from the application’s perspective

Genode’s API level: Consistent and simple nomenclature (client, server, session, RPC object, capability) Synchronous RPC in the strictest sense (RPC stub code generated by C++ templates, no IDL) Capabilities instead of global name spaces (lifetime managed as C++ smart pointer) Asynchronous notifications without payload (like interrupts) → no bit fiddling, “optimizations”

Introducing kernel-agnostic Genode executables 15

slide-34
SLIDE 34

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 16

slide-35
SLIDE 35

Virtual-memory management

Traditional: Page-fault protocol (L4) Memory mappings via the kernel’s IPC or map operations

Introducing kernel-agnostic Genode executables 17

slide-36
SLIDE 36

Virtual-memory management

Traditional: Page-fault protocol (L4) Memory mappings via the kernel’s IPC or map operations Dataspace: Memory object referred by a capability Owner = creator Created via the root of the component tree Can be attached to a component’s local address space Can be shared with others by delegating the capability → shared memory

Introducing kernel-agnostic Genode executables 17

slide-37
SLIDE 37

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 18

slide-38
SLIDE 38

Using a particular kernel

Introducing kernel-agnostic Genode executables 19

slide-39
SLIDE 39

Using a particular kernel

Technical aspects: Source distribution

Introducing kernel-agnostic Genode executables 19

slide-40
SLIDE 40

Using a particular kernel

Technical aspects: Source distribution Tooling (configuration, build system, tool chain, custom scripts)

Introducing kernel-agnostic Genode executables 19

slide-41
SLIDE 41

Using a particular kernel

Technical aspects: Source distribution Tooling (configuration, build system, tool chain, custom scripts) Kernel bindings Intrinsic user-level dependencies (ties to a particular user land)

Introducing kernel-agnostic Genode executables 19

slide-42
SLIDE 42

Using a particular kernel

Technical aspects: Source distribution Tooling (configuration, build system, tool chain, custom scripts) Kernel bindings Intrinsic user-level dependencies (ties to a particular user land) System integration and configuration Booting, logging, debugging, work flows (e. g., menu.lst)

Introducing kernel-agnostic Genode executables 19

slide-43
SLIDE 43

Using a particular kernel

Technical aspects: Source distribution Tooling (configuration, build system, tool chain, custom scripts) Kernel bindings Intrinsic user-level dependencies (ties to a particular user land) System integration and configuration Booting, logging, debugging, work flows (e. g., menu.lst) → Exploration/education costs

Introducing kernel-agnostic Genode executables 19

slide-44
SLIDE 44

Relieving the user from those technicalities

Introducing kernel-agnostic Genode executables 20

slide-45
SLIDE 45

Relieving the user from those technicalities

Custom tooling Bullet-proof integration of 3rd-party code → ports mechanism Kernel-agnostic system-scenario descriptions → run scripts Unified tool chain → blessed bare-metal C++ runtime

Introducing kernel-agnostic Genode executables 20

slide-46
SLIDE 46

The choice of the kernel is almost transparent

Introducing kernel-agnostic Genode executables 21

slide-47
SLIDE 47

The choice of the kernel is almost transparent

Introducing kernel-agnostic Genode executables 21

slide-48
SLIDE 48

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 22

slide-49
SLIDE 49

How the kernel taints the user land

Introducing kernel-agnostic Genode executables 23

slide-50
SLIDE 50

How the kernel taints the user land

  • 1. Inclusion of kernel headers

◮ System-call bindings ◮ Kernel-specific types (IDs, IPC structures, error codes) ◮ Utilities Introducing kernel-agnostic Genode executables 23

slide-51
SLIDE 51

How the kernel taints the user land

  • 1. Inclusion of kernel headers

◮ System-call bindings ◮ Kernel-specific types (IDs, IPC structures, error codes) ◮ Utilities

  • 2. Component code that issues system calls

◮ IPC ◮ Multi-threading, synchronization ◮ Virtual memory management ◮ Hardware access ◮ Kernel-object creation/destruction Introducing kernel-agnostic Genode executables 23

slide-52
SLIDE 52

Decoupling the user land from the kernel

Introducing kernel-agnostic Genode executables 24

slide-53
SLIDE 53

Decoupling the user land from the kernel

  • 1. Clean Genode’s API headers from kernel-specific artifacts

◮ Uniform capability representation Introducing kernel-agnostic Genode executables 24

slide-54
SLIDE 54

Decoupling the user land from the kernel

  • 1. Clean Genode’s API headers from kernel-specific artifacts

◮ Uniform capability representation ◮ Generic IPC message-buffer layout Introducing kernel-agnostic Genode executables 24

slide-55
SLIDE 55

Decoupling the user land from the kernel

  • 1. Clean Genode’s API headers from kernel-specific artifacts

◮ Uniform capability representation ◮ Generic IPC message-buffer layout ◮ Thread manipulation, synchronization Introducing kernel-agnostic Genode executables 24

slide-56
SLIDE 56

Decoupling the user land from the kernel

  • 1. Clean Genode’s API headers from kernel-specific artifacts

◮ Uniform capability representation ◮ Generic IPC message-buffer layout ◮ Thread manipulation, synchronization ◮ Hide address-space layout constraints Introducing kernel-agnostic Genode executables 24

slide-57
SLIDE 57

Decoupling the user land from the kernel

  • 1. Clean Genode’s API headers from kernel-specific artifacts

◮ Uniform capability representation ◮ Generic IPC message-buffer layout ◮ Thread manipulation, synchronization ◮ Hide address-space layout constraints

  • 2. Galvanic separation of kernel-specific from application code

→ distinct ELF objects

Introducing kernel-agnostic Genode executables 24

slide-58
SLIDE 58

Key element: Dynamic linker

Introducing kernel-agnostic Genode executables 25

slide-59
SLIDE 59

Key element: Dynamic linker

The dynamic linker’s split personality: Compile time: shared library

◮ Linked to components ◮ Satisfies dependencies on the Genode API at link time Introducing kernel-agnostic Genode executables 25

slide-60
SLIDE 60

Key element: Dynamic linker

The dynamic linker’s split personality: Compile time: shared library

◮ Linked to components ◮ Satisfies dependencies on the Genode API at link time

Runtime: static binary

◮ Lives inside the component ◮ Obtains and bootstraps the kernel-agnostic executable ◮ Resolves references to the Genode API with itself ◮ Exposes the Genode API as its library interface ◮ Loads and initializes shared libraries Introducing kernel-agnostic Genode executables 25

slide-61
SLIDE 61

Key element: Dynamic linker

The dynamic linker’s split personality: Compile time: shared library

◮ Linked to components ◮ Satisfies dependencies on the Genode API at link time

Runtime: static binary

◮ Lives inside the component ◮ Obtains and bootstraps the kernel-agnostic executable ◮ Resolves references to the Genode API with itself ◮ Exposes the Genode API as its library interface ◮ Loads and initializes shared libraries

free-standing Genode API → generic ABI of the dynamic linker

Introducing kernel-agnostic Genode executables 25

slide-62
SLIDE 62

Genode’s application binary interface (ABI)

ABI definition: Symbol names, types, and meta data Extracted from the concrete dynamic linker instance Cleaned from redundancies

◮ Undefined symbols ◮ Weak C++ symbols

(template instances, inline functions, vtables, type infos)

Cross-checked with all kernels

◮ No inner-framework global symbols ◮ A few kernel-specific parts remain

→ Genode ABI definition: 22 KiB

Introducing kernel-agnostic Genode executables 26

slide-63
SLIDE 63

Crossing CPU-architecture boundaries

Goal: The same ABI across all supported architectures (x86_32, x86_64, ARM, RISC-V)

Introducing kernel-agnostic Genode executables 27

slide-64
SLIDE 64

Crossing CPU-architecture boundaries

Goal: The same ABI across all supported architectures (x86_32, x86_64, ARM, RISC-V) Risk: Mangling of C++ symbols

Introducing kernel-agnostic Genode executables 27

slide-65
SLIDE 65

Crossing CPU-architecture boundaries

Goal: The same ABI across all supported architectures (x86_32, x86_64, ARM, RISC-V) Risk: Mangling of C++ symbols Good: Almost no differences between ARM and x86_32

Introducing kernel-agnostic Genode executables 27

slide-66
SLIDE 66

Crossing CPU-architecture boundaries

Goal: The same ABI across all supported architectures (x86_32, x86_64, ARM, RISC-V) Risk: Mangling of C++ symbols Good: Almost no differences between ARM and x86_32 Shudder: Huge differences between x86_32 and x86_64

Introducing kernel-agnostic Genode executables 27

slide-67
SLIDE 67

Life would be good without size_t

size_t = __SIZE_TYPE__ (compiler-defined)

Introducing kernel-agnostic Genode executables 28

slide-68
SLIDE 68

Life would be good without size_t

size_t = __SIZE_TYPE__ (compiler-defined) x86_32: __SIZE_TYPE__ = unsigned int x86_64: __SIZE_TYPE__ = unsigned long

Introducing kernel-agnostic Genode executables 28

slide-69
SLIDE 69

Life would be good without size_t

size_t = __SIZE_TYPE__ (compiler-defined) x86_32: __SIZE_TYPE__ = unsigned int x86_64: __SIZE_TYPE__ = unsigned long Mangled C++ symbols encode entire function signatures Example: void Connection::upgrade_ram(size_t) x86_32: _ZN10Connection11upgrade_ramEj x86_64: _ZN10Connection11upgrade_ramEm

Introducing kernel-agnostic Genode executables 28

slide-70
SLIDE 70

Life is (almost) good without size_t

No use of __SIZE_TYPE__ by Genode API: Genode::size_t defined as unsigned long → Genode ABI is architecture agnostic Remaining problem: libc uses compiler-defined size_t Fine for C code (symbol == function name w/o arguments) Problem with libc-depending C++ code (like Qt5) → Solution 1: architecture-dependent ABIs → Solution 2: tweak the compiler

Introducing kernel-agnostic Genode executables 29

slide-71
SLIDE 71

Generalization of the ABI mechanism

Introducing kernel-agnostic Genode executables 30

slide-72
SLIDE 72

Generalization of the ABI mechanism

Build system support: ABI definition is translated to an assembly file (almost architecture independent)

Introducing kernel-agnostic Genode executables 30

slide-73
SLIDE 73

Generalization of the ABI mechanism

Build system support: ABI definition is translated to an assembly file (almost architecture independent) Assembly file is compiled/linked into an .abi.so file (shared library that contains only symbols but no code)

Introducing kernel-agnostic Genode executables 30

slide-74
SLIDE 74

Generalization of the ABI mechanism

Build system support: ABI definition is translated to an assembly file (almost architecture independent) Assembly file is compiled/linked into an .abi.so file (shared library that contains only symbols but no code) Library-using targets are linked against the .abi.so file instead of the real library

Introducing kernel-agnostic Genode executables 30

slide-75
SLIDE 75

Generalization of the ABI mechanism

Build system support: ABI definition is translated to an assembly file (almost architecture independent) Assembly file is compiled/linked into an .abi.so file (shared library that contains only symbols but no code) Library-using targets are linked against the .abi.so file instead of the real library ABI formalism for arbitrary libraries! (merely add an ABI definition for a library)

Introducing kernel-agnostic Genode executables 30

slide-76
SLIDE 76

Generalization of the ABI mechanism

Build system support: ABI definition is translated to an assembly file (almost architecture independent) Assembly file is compiled/linked into an .abi.so file (shared library that contains only symbols but no code) Library-using targets are linked against the .abi.so file instead of the real library ABI formalism for arbitrary libraries! (merely add an ABI definition for a library) → Targets can be built without the libraries they depend on.

Introducing kernel-agnostic Genode executables 30

slide-77
SLIDE 77

Immediate benefits

Build directory used to depend on kernel and hardware platform.

Introducing kernel-agnostic Genode executables 31

slide-78
SLIDE 78

Immediate benefits

Build directory used to depend on kernel and hardware platform. New unified build directories: Depend only on hardware platform

Introducing kernel-agnostic Genode executables 31

slide-79
SLIDE 79

Immediate benefits

Build directory used to depend on kernel and hardware platform. New unified build directories: Depend only on hardware platform Kernel-agnostic targets are linked dynamically (almost all components) Kernel-specific targets are named after the kernel (ld-nova.lib.so, core-nova, timer driver) → build results can peacefully coexist

Introducing kernel-agnostic Genode executables 31

slide-80
SLIDE 80

Immediate benefits

Build directory used to depend on kernel and hardware platform. New unified build directories: Depend only on hardware platform Kernel-agnostic targets are linked dynamically (almost all components) Kernel-specific targets are named after the kernel (ld-nova.lib.so, core-nova, timer driver) → build results can peacefully coexist Choice of kernel not before running a scenario: make run/demo KERNEL=nova

Introducing kernel-agnostic Genode executables 31

slide-81
SLIDE 81

Outline

  • 1. Kernel diversity - What’s the appeal?
  • 2. Bridging the gap between kernels

Notion of components Raising the level of abstraction of IPC Virtual-memory management Custom tooling

  • 3. From a uniform API to binary compatibility
  • 4. Future prospects

Introducing kernel-agnostic Genode executables 32

slide-82
SLIDE 82

Future prospects

Package management Distinction between source and API/ABI packages → Loose coupling of packages Binary packages independent of the used kernel

Introducing kernel-agnostic Genode executables 33

slide-83
SLIDE 83

Future prospects

Package management Distinction between source and API/ABI packages → Loose coupling of packages Binary packages independent of the used kernel Multiple levels of API/ABI stability

Introducing kernel-agnostic Genode executables 33

slide-84
SLIDE 84

Future prospects

Package management Distinction between source and API/ABI packages → Loose coupling of packages Binary packages independent of the used kernel Multiple levels of API/ABI stability Two orthogonal directions

  • 1. Successive hardening of the foundation, transparent to users
  • 2. Scaling the software stack with a fixed target

Introducing kernel-agnostic Genode executables 33

slide-85
SLIDE 85

Unique solutions, enabled by Free Software

Introducing kernel-agnostic Genode executables 34

slide-86
SLIDE 86

Unique solutions, enabled by Free Software

Shaping the entire vertical software stack:

Tool chain ↔ Work-flow automation ↔ Quality assurance Build system ↔ Source-code management ↔ Package management Dynamic linker (cross-kernel binary compatibility) C runtime, C++ runtime (encapsulating legacies) VFS infrastructure (component-level customiztions) Init and system configuration (session routing) Genode ABI and API (enforcing a safe C++ dialect) Kernel (base-hw, scheduling, kernel-resource management) Component interfaces (multi-component applications) User interface ↔ System management

Introducing kernel-agnostic Genode executables 34

slide-87
SLIDE 87

Unique solutions, enabled by Free Software

Shaping the entire vertical software stack:

Tool chain ↔ Work-flow automation ↔ Quality assurance Build system ↔ Source-code management ↔ Package management Dynamic linker (cross-kernel binary compatibility) C runtime, C++ runtime (encapsulating legacies) VFS infrastructure (component-level customiztions) Init and system configuration (session routing) Genode ABI and API (enforcing a safe C++ dialect) Kernel (base-hw, scheduling, kernel-resource management) Component interfaces (multi-component applications) User interface ↔ System management

→ Cross-pollination between different levels

Introducing kernel-agnostic Genode executables 34

slide-88
SLIDE 88

Unique solutions, enabled by Free Software

Shaping the entire vertical software stack:

Tool chain ↔ Work-flow automation ↔ Quality assurance Build system ↔ Source-code management ↔ Package management Dynamic linker (cross-kernel binary compatibility) C runtime, C++ runtime (encapsulating legacies) VFS infrastructure (component-level customiztions) Init and system configuration (session routing) Genode ABI and API (enforcing a safe C++ dialect) Kernel (base-hw, scheduling, kernel-resource management) Component interfaces (multi-component applications) User interface ↔ System management

→ Cross-pollination between different levels → Simple and holistic solutions!

Introducing kernel-agnostic Genode executables 34

slide-89
SLIDE 89

The Book “Genode Foundations”

GENODE

Operating System Framework

Foundations

Norman Feske

https://genode.org/documentation/genode-foundations-16-05.pdf

Introducing kernel-agnostic Genode executables 35

slide-90
SLIDE 90

Thank you

Genode OS Framework https://genode.org Genode Labs GmbH https://www.genode-labs.com Source code at GitHub https://github.com/genodelabs/genode

Introducing kernel-agnostic Genode executables 36