Hi Stefan,
The past year to me meant a lot of long standing improvements at the very ground of the framework to actually become reality. Especially the re-design and implementation of our custom kernel's scheduler algorithm, elimination of exceptions within core, and kernel (base-hw), modern x86 hardware support for base-hw, accurate page-table memory accounting, and some more. Moreover, I was involved in enabling new hardware like the armStone i.MX 8MP SoC including a demonstrator for the embedded world exhibition, USB stabilization work, and some more maintainance work items.
I really cannot put into words the gratitude I feel for your sense of responsibility for base-hw that you have put on display in 2025. The scope of this work was at times surprising to both of us. Your desire for quality and the removal of remaining uncertainties was beautiful to witness. Your priorization of this important kernel curation work over your original USB plans was only natural in my opinion. No regrets!
Beside the re-organization of the USB API (to have explicit host controller driver clients), I'd like to have support for USB Audio. Not only, but also as a practical example to stress-test the ability to have distinct drivers of different USB interfaces of one and the same USB device (AUDIO + HID of a headset). Moreover, my framework laptop has no internal ethernet card, but one that is bound via USB. Unfortunately, our USB network driver does not support it resp. doesn't work correctly here. I would like to strengthen the USB network support therefore.
Beside making the USB multiplexer more robust, the platform driver needs some internal reworks too, like removing exceptions, explicit DMA sessions to account DMA memory for distinct clients in separate, and interrupt session adaptions to support MSI and MSI-x better (more than one interrupt per device).
Now that our custom kernel is used on a daily base by ourselves, I see the necessity of more maintainance work in 2026 here, like building it without C++ exception support compiler-wise (minor issue now), strengthen its robustness in general, do some x86-related and generic optimizations, e.g. rethink system calls to combine signals and ipc in one call.
This is a perfectly sensible plan worth pursuing.
I'm hesitant to bring up new features or applications here, because I see myself confronted with the maintainance of some important components on several hardware platforms already, and of course we'll have to do driver updates and support of new modern hardware this year too. Therefore, I don't see myself porting additional native applications (e-mail client), or enabling non-functional features (like full-disk encryption) although I would be very happy about it.
I agree.
Each year, our road map tends to be unrealistically optimistic at some points. When missing a few of the goals, there might be a slight feel of defeat. But it shouldn't. In contrast to a contractual obligation like commissioned project, our road map is just a casual plan after all, a guiding rail for us developers, but no definite guarantee.
Yet, I recognize your call for staying realistic. ;-)
Cheers Norman