- l4-hackers - example.com Site

Question regarding planned features and major updates
by David Q 15 Jul '26

15 Jul '26

Hello L4Re team, I see the codebase and the documentation have been updated quite frequently recently, with a pretty big emphasis on ARM and some completely new features and changes. Are there any plans for a major feature addition/update in the very near future (2 week timeframe)? Also, as I understand it, all releases have underwent strict review before releasing, but are there specific versions that are especially recommended? Thank you so much :) David

2 2

Comprehension question: vcpu vs extended vcpu
by David Q 01 Jun '26

01 Jun '26

Hello L4 hackers, Hope y'all are doing well. I am back with another question, this time regarding vcpus and its "extended" add-on. From reading the documentation and some tinkering, it seems the default vcpu is quite capable of performing virtualization tasks as the virtualized CPU. 1. When looking at code in uvmm, it seems the "normal" vcpu is used for virtualization by default, is this correct? 2. When should we need to use the "extended" add on? a. It seems "extended" uses additional hardware assisted virtualization features, is this understanding correct? b. If the assumption in a. is correct, what pros and cons does running "extended" have? (Maybe additional safety/stability improvements?) c. Are there hardware limitations for running in "extended" mode? (For example, is A76 supported?) Thank you so much for your attention :) Best, David

2 2

NOVA multitasking
by Nate 30 May '26

30 May '26

Hi L4 hackers! I've been quite interested in the NOVA microhypervisor, and thought because it is based off L4 and has similar architecture, you guys might be able to help. Now, I've always thought NOVA was a cool kernel thing, and wanted to make an OS around it. However, the only thing online that guides you is Genode, which doesn't really help you make an OS, but rather a domain-specific wrapper around Genode. So, I did some research on the kernel itself and attempted to make my own OS without Genode. I managed to get a simple root task. Here is start.S ``` .global _start .extern root_main .section .data .align 16 stack: .space 16384 stack_top: .text _start: mov %rsp, %rdi lea stack_top(%rip), %rsp and $-16, %rsp call root_main .hang: hlt jmp .hang ``` Here is root.c ``` #include <stdint.h> #include "thread.h" #include "hypercalls.h" #include "io.h" void thread_uno(void) { while (1) { serial_print_locked("Hello from thread!\r\n"); for (volatile int i = 0; i < 5000000; i++); } } void root_main(void *hip) { mword rax, rdi; nova_call((SEL_KERNEL_OBJ_SPACE << 8) | NOVA_SYS_CTRL_PD, SEL_MAIN_OBJ_SPACE, (KSEL_HOST_PIO << 12), (LOCAL_SEL_HOST_PIO << 12) | 0xf, 0, &rax, &rdi); nova_call((SEL_KERNEL_OBJ_SPACE << 8) | NOVA_SYS_CTRL_PD, SEL_MAIN_OBJ_SPACE, (KSEL_MAIN_PIO << 12), (LOCAL_SEL_MAIN_PIO << 12) | 0xf, 0, &rax, &rdi); nova_call((LOCAL_SEL_HOST_PIO << 8) | NOVA_SYS_CTRL_PD, LOCAL_SEL_MAIN_PIO, (0x3F8 << 12) | 3, (0x3F8 << 12) | 1, 0, &rax, &rdi); Thread t = spawn_thread(thread_uno, 20); (void)t; while (1) { serial_print_locked("Hello from main!\r\n"); for (volatile int i = 0; i < 5000000; i++); }} ``` And, io.c ``` #include "hypercalls.h" #include "io.h" static inline void outb(uint16_t port, uint8_t val) { asm volatile("outb %0, %1" : : "a"(val), "Nd"(port)); } static inline uint8_t inb(uint16_t port) { uint8_t val; asm volatile("inb %1, %0" : "=a"(val) : "Nd"(port)); return val; } volatile int serial_lock = 0; void serial_putc(char c) { while (!(inb(0x3F8 + 5) & 0x20)) asm volatile("pause"); outb(0x3F8, c); } void serial_print_locked(const char *s) { while (__atomic_test_and_set(&serial_lock, __ATOMIC_ACQUIRE)) asm volatile("pause"); while (*s) serial_putc(*s++); __atomic_clear(&serial_lock, __ATOMIC_RELEASE); } void serial_print_hex_locked(mword val) { char buf[19]; buf[0] = '0'; buf[1] = 'x'; for (int i = 17; i >= 2; i--) { int nibble = val & 0xf; buf[i] = nibble < 10 ? '0' + nibble : 'a' + nibble - 10; val >>= 4; } buf[18] = 0; const char *p = buf; while (*p) serial_putc(*p++); } void show_status(const char *msg, mword rax, mword rdi) { serial_print_locked(msg); serial_print_locked(" [RAX:"); serial_print_hex_locked(rax); serial_print_locked(" RDI:"); serial_print_hex_locked(rdi); serial_print_locked("]\r\n");} ``` So, this works simple enough. But, the next thing I want is multitasking. So, I made these two files, hypercalls.c ``` #include "hypercalls.h" void nova_call(mword rdi, mword rsi, mword rdx, mword rax, mword r8, mword *out_rax, mword *out_rdi) { mword res_rax, res_rdi; asm volatile( "mov %6, %%r8\n" "syscall\n" : "=a"(res_rax), "=D"(res_rdi) : "D"(rdi), "S"(rsi), "d"(rdx), "a"(rax), "r"(r8) : "rcx", "r11", "r8", "memory" ); if (out_rax) *out_rax = res_rax; if (out_rdi) *out_rdi = res_rdi; } ``` And thread.c ``` #include "hypercalls.h" #include "thread.h" #include "io.h" #define MAX_THREADS 16 uint8_t thread_stacks[MAX_THREADS][4096] __attribute__((aligned(4096))); uint8_t thread_utcbs[MAX_THREADS][4096] __attribute__((aligned(4096))); uint8_t worker_stacks[MAX_THREADS][4096] __attribute__((aligned(4096))); uint8_t driver_utcbs[MAX_THREADS][4096] __attribute__((aligned(4096))); static mword worker_utcb_addrs[MAX_THREADS]; int thread_slot = 0; mword next_sel = 128; typedef struct { mword entry; mword stack; } StartupArgs; static StartupArgs pending_startup[MAX_THREADS]; static mword alloc_sel(mword count) { mword s = next_sel; next_sel += count; return s; } void startup_handler(mword id) { if (id >= MAX_THREADS) while(1); mword *utcb = (mword *)worker_utcb_addrs[id]; utcb[4] = pending_startup[id].stack; utcb[16] = 0x202; utcb[17] = pending_startup[id].entry; mword rax, rdi; nova_call(NOVA_SYS_IPC_REPLY, 0x1a, 0, 0, 0, &rax, &rdi); while(1) { asm volatile("pause"); } } Thread spawn_thread(void (*entry)(void), int priority) { int slot = thread_slot++; mword worker_ec = alloc_sel(1); mword driver_ec = alloc_sel(1); mword sc_sel = alloc_sel(1); mword portal_base = (next_sel + 255) & ~255UL; next_sel = portal_base + 256; mword pt_startup = portal_base + 0x1e; mword stack_top = (mword)&thread_stacks[slot][4096]; mword worker_utcb = (mword)thread_utcbs[slot]; mword driver_utcb = (mword)driver_utcbs[slot]; worker_utcb_addrs[slot] = worker_utcb; pending_startup[slot].entry = (mword)entry; pending_startup[slot].stack = stack_top; mword rax, rdi; mword worker_stack_top = (mword)&worker_stacks[slot][4096]; nova_call((worker_ec << 8) | NOVA_SYS_CREATE_EC, SEL_MAIN_PD, worker_utcb, 0, worker_stack_top, &rax, &rdi); show_status(" Worker EC:", rax, rdi); nova_call((pt_startup << 8) | NOVA_SYS_CREATE_PT, SEL_MAIN_PD, worker_ec, (mword)startup_handler, 0, &rax, &rdi); nova_call((pt_startup << 8) | 11, slot, 0, 0, 0, &rax, &rdi); nova_call((driver_ec << 8) | (2 << 4) | NOVA_SYS_CREATE_EC, SEL_MAIN_PD, driver_utcb, portal_base, stack_top, &rax, &rdi); show_status(" Driver EC:", rax, rdi); nova_call((sc_sel << 8) | NOVA_SYS_CREATE_SC, SEL_MAIN_PD, driver_ec, ((mword)priority << 16) | 10000, 0, &rax, &rdi); show_status(" SC:", rax, rdi); return (Thread){ driver_ec, sc_sel }; } ``` At this point, I have no clue what I am doing wrong, the output is just ``` [ -1] RSDT: 0x3ffe2351 OEM:BOCHS TBL:BXPC REV: 1 LEN: 56 (ok) [ -1] FACP: 0x3ffe2149 OEM:BOCHS TBL:BXPC REV: 3 LEN: 244 (ok) [ -1] APIC: 0x3ffe223d OEM:BOCHS TBL:BXPC REV: 3 LEN: 120 (ok) [ -1] HPET: 0x3ffe22b5 OEM:BOCHS TBL:BXPC REV: 1 LEN: 56 (ok) [ -1] MCFG: 0x3ffe22ed OEM:BOCHS TBL:BXPC REV: 1 LEN: 60 (ok) [ -1] WAET: 0x3ffe2329 OEM:BOCHS TBL:BXPC REV: 1 LEN: 40 (ok) [ -1] ACPI: Version 3.0 Profile 0 Features 0x84a5 Boot 0x2 [ -1] FACS: Hardware 0x0 Flags 0x0 Wake 0x0/0x0 [ -1] PCIE: 0xb0000000 Seg 0x0000 Bus 0x00-0xff [ -1] PCIE: 8086:29c0 06-00-00 D0 0000:00:00.0 [ -1] PCIE: 1234:1111 03-00-00 D0 0000:00:01.0 [ -1] PCIE: 8086:10d3 02-00-00 D0 PMI PCIE MSI MSIX 0000:00:02.0 [ -1] PCIE: 8086:2918 06-01-00 D0 0000:00:1f.0 [ -1] PCIE: 8086:2922 01-06-01 D0 MSI 0000:00:1f.2 [ -1] PCIE: 8086:2930 0c-05-00 D0 0000:00:1f.3 [ -1] HPET: 0xfed00000 [ 0] CORE: 00:000.0 6:5e:3:0 [0x1] Intel Core Processor (Skylake) [ 0] TIME: 386ms 0ms/0ms [ 0] INFO: NOVA: 0x000000003b000000-0x000000003f000000 [ 0] INFO: MBUF: 0x000000003ec8e000-0x000000003ec8f000 [ 0] INFO: ROOT: 0x0000000000102000-0x0000000000149000 [ 0] INFO: ACPI: 0xf52c0 [ 0] INFO: UEFI: 0xffffffffffffffff 0 0 0 [ 0] INFO: FREQ: 2719941700 Hz [ 0] INFO: SBW#: OBJ:18 HST:35 GST:36 DMA:0 PIO:16 MSR:13 [ 0] INFO: HST#: 32 + 2 [ 0] INFO: GST#: 256 + 2 [ 0] INFO: CPU#: 1 Worker EC: [RAX:0x0000000000000000 RDI:0x0000000000000000] Driver EC: [RAX:0x0000000000000100 RDI:0x0000000000000008] SC: [RAX:0x0000000000142710 RDI:0x0000000000000005] Hello from main! Hello from main! Hello from main! Hello from main! Hello from main! Hello from main! Hello from main! Hello from main! Hello from main!Hello from main! (forever) ``` As you can see, no second thread. I heard that the RAX and RDI values should all be `0x0000000000000000` if it worked? Would anyone be able to help me? Thanks!

1 0

Kernel allocated memory not visible in L4Re virtual device despite correct physical RAM mapping
by stephen.yang 14 May '26

14 May '26

Hi l4-hackers, I am trying to pass a kernel-allocated memory buffer to a virtual device, but I am running into an issue. I would appreciate any help or suggestions. 1.Kernel side(driver) In my platform driver, I allocate memory using devm_kzalloc, write a string into it, and pass its physical address to the device via an MMIO register: …… void* buf = devm_kzalloc(&pdev->dev, 0x200, GFP_KERNEL); if (!buf) return -ENOMEM; phys_addr_t pa = virt_to_phys(buf); char *str = "hi stephen"; memcpy(buf, str, strlen(str) + 1); wmb(); writeq((u64)pa, hb->base + 0x00); …… My understanding is: allocate kernel memory → write data → pass physical address to the device. 2. Memory layout I observed that the allocated physical address falls within the RAM regions configured via bootargs : 0x66200000 - 0x6fffffff So my assumption was that if the virtual device maps this physical memory region, it should be able to access the data written by the kernel. 3. Virtual device side (L4Re) On the virtual device side, I map the physical memory using L4Re RM attach: void write(unsigned reg, char /*size*/, l4_uint64_t value, unsigned) { if (reg == 0x00) { addr = value; auto d = L4Re::Env::env()->get_cap<L4Re::Dataspace>("lram"); l4_addr_t vaddr; l4_addr_t base = 0x66200000; l4_addr_t size = 0x09E00000; int r = L4Re::Env::env()->rm()->attach( &vaddr, size, L4Re::Rm::F::Search_addr | L4Re::Rm::F::RW | L4Re::Rm::F::Cache_uncached, L4::Ipc::make_cap_rw(d), 0, L4_PAGESHIFT); if (r) { printf("can't attach hb memory\n"); return; } char *dst = reinterpret_cast<char *>(vaddr + (addr - base)); for (int i = 0; i < 20; i++) { printf("%02x ", (unsigned char)dst[i]); } printf("\n"); printf("get msg for guest: %s\n", dst); } } 4.Problem However, I cannot read the string written by the kernel. The memory content I get appears to be uninitialized or unrelated data. 5.Question I can confirm that the lram dataspace capability does correctly correspond to the physical memory region 0x66200000 - 0x6fffffff, and this region is valid and usable RAM on the system. I am unsure where the issue lies: (1) Is this approach (kernel allocation → pass physical address → direct mapping in virtual device) actually valid? (2) Could this be a cache coherence / DMA issue? (3) Or is there something incorrect in my L4Re RM attach usage? Any insights would be greatly appreciated.

2 6

Mounting the Sd card on the L4re for Imx 95.
by Marka Sriharsha 08 Feb '26

08 Feb '26

The L4Re version I am using is r-2025-W48. Initially, I attempted to boot using the initramfs-based method. In this approach, I converted the uImage into a raw bin image, because loading the uImage directly resulted in a Bad kernel image error, likely due to the default uImage header handling. After flashing the converted binary to the SD card, the system booted but consistently got stuck during early boot. Even when different load addresses are specified in U-Boot, the kernel is always relocated to a fixed address (0x90080000). This address overlaps with a reserved memory region (e.g., vpu_boot@a0000000), leading to a region overlap error and reboot. I'm attracting the log (Initramfs.txt). After this, I switched to the SD card hardware passthrough method. Following the i.MX documentation, I prepared the SD card as follows: Partition 1: FAT partition containing bootstrap.uimage and the i.MX95 device tree Partition 2: Root filesystem As suggested, I updated the configuration (.cfg) file by following the tutorial, and this resolved the console misconfiguration issue. The system now boots correctly, and I am able to see the console output. For reference, I am attaching the boot logs(Boot_partition_2.txt) Although the system boots successfully, the SD card root partition is not being detected or mounted. While following the documented steps to enable SD card access, the boot process ends with a “no device found” error for the SD card. After further debugging, I noticed that for i.MX95, there is nohw_devices.iofile available in the following repository: [https://github.com/kernkonzept/io/tree/master/io/configs] Because of this, it is unclear how the SD/MMC hardware should be described for i.MX95, and the block device does not appear during boot. For reference, I am attaching the boot logs(Boot_partition_3.txt) Is there an official hw_devices.io configuration available for i.MX95? or without the hw_device.io also we can mount the sd card? Any guidance or example configuration would be very helpful for mounting the rootfs.

2 1

Beyond the Bricks: How Google's Block Breaker Doodle Reminds Us of the Joy of Play
by blockbreakerapk10174＠gmail.com 06 Feb '26

06 Feb '26

In the relentless digital stream of our daily lives—a torrent of emails, notifications, and curated content—a moment of pure, unadulterated play can feel like a radical act. It was within this context that, on a seemingly ordinary day, millions of people worldwide were greeted by a delightful surprise on Google’s homepage: the Google Block Breaker Doodle. This wasn’t just a static logo; it was a fully playable, wonderfully crafted version of the classic arcade game, Breakout. With a click, the world’s most ubiquitous search portal transformed into a minimalist arcade, inviting users to smash a wall of colorful <a href="https://blockbreaker.ws/">google block breaker doodle</a> bricks with a bouncing pixel. The phenomenon was more than a nostalgic trip; it was a masterclass in design philosophy, a commentary on workplace culture, and a potent reminder of a fundamental human need. The genius of the Google Block Breaker Doodle lay in its elegant simplicity and its deep-rooted heritage. The original Breakout, released by Atari in 1976, is itself a piece of tech legend. It was a direct descendant of Pong, emphasizing solitary focus and rhythmic precision. More intriguingly, its original development involved a young Steve Jobs and Steve Wozniak, who were tasked with creating its circuit board. For Google to choose this game was a wink to its own Silicon Valley lineage, connecting the dots from the garage-built ethos of early computing to the sleek, global platform of today. The Doodle didn’t just reference a game; it honored a foundational moment in digital interactivity. But the impact went far beyond history. The user experience was perfectly calibrated. The mechanics were instantly understandable: move the paddle, bounce the ball, break the blocks. There were no tutorials, no loot boxes, no complex narratives. The objective was clear, the feedback immediate (the satisfying disappearance of a brick), and the failure state gentle—a chance to try again instantly. This created a state of "flow," that psychological condition of complete immersion and focused enjoyment. In a world of endless scrolling and multitasking, the Google Block Breaker Doodle offered a rare commodity: a single, simple task that commanded full attention. It was a digital mindfulness exercise disguised as a game. The timing and placement of the Doodle were equally significant. By situating this portal to play on the default homepage for countless browsers, Google shattered the traditional boundary between "work" and "play." For a brief moment, the tool we use for research, communication, and productivity became a site of leisure. This wasn’t an app you had to seek out; it was presented, almost insistently, as an alternative path. It encouraged what modern productivity gurus might call a "micro-break"—a short, intentional pause to reset the brain. The message was subtle but powerful: creativity and efficiency are not antithetical to play; they are often fueled by it. The Google Block Breaker Doodle became a sanctioned, global five-minute recess, challenging the grim grind of hustle culture. Furthermore, the Doodle served as a brilliant, unspoken showcase of web technology. This was no mere Java applet from the early 2000s. It was a smooth, responsive, and visually pleasing experience built with modern web standards, demonstrating what a browser could do without any plugins or downloads. It was a testament to the sophistication of accessible web design, proving that complex interactivity could be delivered instantly and seamlessly to anyone with an internet connection. In this way, the playful facade was also a technical flex, a demonstration of Google’s core competency in making the web a more dynamic canvas. On a societal level, the Doodle created a shared cultural moment. Social media lit up with high scores, strategies, and good-natured commiseration over near-misses. Colleagues compared scores by the watercooler. It democratized a specific joy, creating a common reference point across generations. Older users relived childhood memories in arcades or on early home consoles, while younger ones discovered a genre stripped bare of modern gaming’s complexities. The Google Block Breaker Doodle acted as a universal language, speaking through the simple verbs of aim, bounce, and break. Ultimately, the lasting lesson of the Google Block Breaker Doodle is about the enduring human need for purposeless purpose. We are wired to derive satisfaction from mastering simple systems, from seeing a clear cause and effect, and from engaging in activities where the only goal is the activity itself. In our increasingly optimized and outcome-driven lives, we often engineer this joy out of existence. The Doodle was a gentle intervention, a reminder that play is not frivolous. It is essential for cognitive maintenance, sparking joy, relieving stress, and fostering a creative mindset. Google, a company built on algorithms and data, used its most prized real estate to advocate for something beautifully analog in spirit: the click of a mouse, the bounce of a ball, the shattering of a digital wall. The Google Block Breaker Doodle was more than a clever homage; it was a manifesto in interactive form. It argued that within the cold architecture of code and connectivity, there must always be room for a paddle, a ball, and a wall of bricks waiting to be broken. It reminded us that sometimes, the most productive thing we can do is to simply play.

1 0

VMs on L4Re
by Quang 16 Jan '26

16 Jan '26

Dear L4Re team, I'm following your guidance on the steps to get the RPi 4B running with L4Re (https://l4re.org/bsp/rpi.html) I can set up and run very well with your steps. However, I think an image, especially l4re_vm-multi_rpi4.elf, is only for 3 VMs. Could you help me figure out how I can increase the number of VMs, and each VM will run on a different OS, such as Ubuntu, Red Hat, or Kali Linux? Thank you for your support, and have a nice day. Best regards, Quang

2 2

custom virtio
by Baruch Burstein 26 Dec '25

26 Dec '25

Hi all, I am looking into implementing a custom backend for a virtio console (I hope I am using the right terminology. The frontend will be in a VM managed by uvmm). I found 2 seemingly unrelated parts of the code named virtio-console, one under uvmm/server/src/virtio_console.[cc|h] and one under l4virtio/include/server/virtio-console. I am wondering why there are 2, what the difference is and when to use each one? There generally seem to be multiple things named virtio* in uvmm/server/src/, uvmm/server/src/device/, as well as separate repos like the aforementioned l4virtio or virtio-net. Thank you in advance for helping clear this up for me

2 1

Multiple targets in one package
by Baruch Burstein 03 Dec '25

03 Dec '25

Hi. I am trying to build multiple apps in one package. I tried the following but am getting linker errors (of all things!) ``` PKGDIR ?= ../.. L4DIR ?= $(PKGDIR)/../.. TARGET = app1 SRC_CC = app1.cc common.cc REQUIRES_LIBS = libio cxx_libc_io cxx_io libstdc++ include $(L4DIR)/mk/prog.mk TARGET = app2 SRC_CC = app2.cc common.cc REQUIRES_LIBS = libio cxx_libc_io cxx_io libstdc++ include $(L4DIR)/mk/prog.mk ``` What is the right way to do this?

2 1

[FOSDEM'26] Call for Participation: Microkernel and Component-Based OS Devroom
by Sebastian Sumpf 04 Nov '25

04 Nov '25

Hi there, here the CfP for FOSDEM'26: We are happy to announce the CfP for the "Microkernel and Component-Based OS" devroom at the upcoming FOSDEM 2026. Developers and users of various free and open-source microkernel-based and component-based operating systems will meet again at FOSDEM during the weekend of January 31st and February 1st 2026 and will share a developer room. The Microkernel and Component-Based OS devroom is currently looking for your participation in the form of proposals for talks, demos and other related activities. Possible topics for the devroom include, but are not limited to: * Introduction of a specific OS or framework * Design of subsystems and the general architecture of an OS * Languages, tools and toolchains used * Enabling support for hardware architectures, devices and programming languages * Development processes, debugging * Maintenance, testing and release engineering * Safety, security and robustness * Trends and challenges * Research and open questions * Community and governance * Use cases, experiences and status updates * Best practices and lessons learned * Live demos Important Dates The deadline for submitting proposals is December 1, 2025 (23:55 CET). Please use the FOSDEM website at https://fosdem.org/submit, select the track "Microkernel and Component-Based OS" and include at least the following information: * Title of your proposal * Short abstract (one or two paragraphs) * Duration (20 - 30 minutes, including demos and Q&A) * Your full name * Your short bio The devroom schedule (with accepted talks) will be announced on the devroom website at https://fosdem.org/2026/schedule/track/microkernel by December 15, 2025. The schedule will also be posted to the devroom mailing list and the speakers will be notified via email. Like previous years, the devroom will take place as an in-person event at the ULB Campus Solbosch in Brussels, Belgium during the second half of February 1, 2026 (Sunday). Due to the high number of submissions that FOSDEM received again this year, our devroom has only been allocated half a day. Therefore, the final decision on the duration of the talks will be made by the devroom organizers based on the number of accepted proposals. Given these restrictions, eight to nine half hour slots with a speaking time of 20 to 25 minutes and 5 to 10 minutes of Q&A form the upper limit. Requirements The communication language of the devroom is English. All content must relate to free and open-source software. By participating in the event, you agree to the publication of your talk recordings, slides and other content provided under the same CC-BY license as all other FOSDEM content. All participants are expected to adhere to the Code of Conduct: https://fosdem.org/2026/practical/conduct/ Contact For the 2026 edition, the organizers of the devroom are * Sebastian Sumpf (sebastian.sumpf [at] genode-labs.com) * Josef Söntgen (josef.soentgen [at] genode-labs.com) For any comments, questions and suggestions, please do not hesitate to contact us directly or via microkernel-devroom-manager at fosdem.org. Announcements and inquiries are additionally available through the devroom mailing list https://lists.fosdem.org/listinfo/microkernel-devroom About the Devroom Since the first Microkernel OS Devroom at FOSDEM 2012, this devroom has been a part of each subsequent FOSDEM (with slight variations of the name). The focus gradually widened to include component-based and other operating systems. It has now become somewhat of a tradition for the open-source operating systems community, a kind of "extended family meeting" and it is one of the very few places where microkernel and operating-system enthusiasts meet regularly. To date, over two dozen projects have participated in one way or another. Many of the projects face similar challenges but come up with partially different solutions. Therefore, the goal of the devroom is to bring the various projects together, let them exchange ideas, cross-pollinate and socialize. As in the past, the devroom will offer the stage both to established community members and to newcomers. Our goal is to select talks in an inclusive manner and to create a balanced and unbiased schedule, while keeping the quality of the devroom as high as in previous years. About FOSDEM FOSDEM is a two-day conference organized by volunteers to promote the widespread use of free and open-source software. FOSDEM is widely recognized as one of the largest and best such events worldwide. FOSDEM covers a wide spectrum of free and open-source software and hardware projects and offers a platform for people to collaborate. To this end, FOSDEM has set up developer rooms (devrooms) where teams can meet and showcase their projects. Devrooms are a place for teams to discuss, hack and publicly present new ideas, latest results, lightning talks, news and proposals. Besides developer rooms, FOSDEM also offers main tracks, lightning talks, certification exams and project stands. In recent years, FOSDEM has been hosting more than 5000 developers annually at the ULB Solbosch Campus in Brussels, Belgium. The participation in FOSDEM is totally free and requires no registration, although the organizers gratefully accept donations and sponsorship. Devroom Dinner Over the years, it has become a tradition that devroom speakers and enthusiasts meet for dinner somewhere in Brussels after the event to continue discussions, socialize and meet old and new friends. We plan to follow that tradition in some form as well in 2026 and will inform you about the exact arrangements later. Hope to see all of you in Brussels! Regards, Sebastian -- Sebastian Sumpf Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0