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
--
Dr.-Ing. Norman Feske
Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Archived at
https://lists.genode.org/mailman3/hyperkitty/list/[email protected]/message/EASN4CP7WQCCUA3GCUC4WTQKJKGK37JG/
