Hello everyone,
the turn of years is approaching, which prompts me to pick up our fine tradition of jointly brainstorming the topics of the year to come.
Below, I'm not speaking for the project but share my personal perspective. Let me start with a brief reflection on 2024, followed by my ambitions for 2025.
Review of 2024
Following our past year's discussion, we settled on "Sculpt OS usability" as the primary focus for 2024. The items on the roadmap envisioned a broad variety of topics, ranging from challenging low-level mechanisms to end-user conveniences.
From my perspective, the two biggest breakthroughs had been suspend/resume on x86 (added in May) and multi-monitor support (added in October). Both topics were not merely approached as singular features but as architectural enhancements. Suspend/resume challenged our perspective on driver life-cycles, externalizing state, device re-acquisition, up to the dynamic driver management by Sculpt OS. Our desire for multi-monitor support culminated in a largely redesigned GUI stack, as a system-holistic endeavor. Both lines of work made the architecture of Sculpt OS much stronger.
Regarding my original plans for user conveniences (file browser etc.), I must declare defeat. Instead of working on these user-visible features, I turned a significant part of my attention to consolidation work: Gradually removing the use of C++ exceptions, cultivating C++20, improving code safety, and accelerating our workflows be refining our build system and tools.
Outside my own working topics, I vastly enjoyed watching our team embracing DDE-Linux to full extent. Reflecting upon our small team's ability to track the current Linux kernel for our large driver base with such an agility makes me more than happy. A similar source of happiness is the way of how the Goa SDK and the new Applications book evolved. It reveals plainly and clearly how all the parts of the machinery fit super nicely together.
Any regrets? Two things come into mind. First, my over-promising to deliver user conveniences. Topics like the on-target docs view or a file manager are user-visible and fun to build. But I was not able to justify prioritizing those over the work on framework internals as my core expertise. I somewhat regret having promised too much. Second, the PinePhone hasn't become a regular part of my life. That's not the fault of the PinePhone. But I came to terms that I may simply not be a phone person, never having owned a smart phone after all. Once I called the exciting ride of bringing Genode to the PinePhone a success, my personal motivation to push things further forward plummeted somewhat.
My plans for 2025
I want to focus my Genode work on rigidity, clarity, and performance.
1. Following my consolidation work of 2024, I long for getting the C++ runtime removed from the base framework. Another tempting idea for simplification is the merging of core's CPU service into the PD service. This work will make Genode more simple and thereby more trustworthy.
2. I'm very curious to explore the idea of replacing XML, outlined at https://genodians.org/nfeske/2024-12-20-moving-on-from-xml If this goes as intended, Genode and Sculpt OS will gain in terms of interactive ergonomics, clarity, and joy to develop for.
3. Given how easy the porting of software has become, thanks to Goa, I'd strive for moving more of my work outside a Linux VM. For this, libraries like the libc and VFS require further optimization. This goes hand in hand with the need for better tools for analysing performance bottlenecks of complex dynamic workloads. As an iconic goal, it would be fantastic to have a simple version of Goa running directly on Sculpt OS by the end of 2025.
In addition, I'd like to catch up on my plans of 2024 regarding user-visible Sculpt OS features, introducing a documentation view, a simple file manager, and a convenient way to save settings. I will also definitely wrap up the multi-monitor window management that I have built during the past two months.
My wishes for 2025
Outside the realm of my own working topics, I'd love to eventually switch to the base-hw kernel on my Framework laptop. I'd also highly appreciate an update of the Chromium engine for the Falkon web browser. Don't we all want to participate in https://genode.discourse.group using a browser directly on Sculpt OS? ;-)
What is your perspective on Genode in 2024 and for 2025?
- Has Genode's development during 2024 been in your interest? - Or do you find important aspects neglected? - How was your practical experience with Genode in 2024? - Which directions would you regard as most exciting or pressing? - What are your personal interests and plans for 2025?
I'm looking forward to learn about your experiences, plans, and ideas. Like every year, I'll do my best to distill a rough plan for 2025 out from our joint discussion. The road map will be finalized around mid of January.
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
What is your perspective on Genode in 2024 and for 2025?
Hello Norman and all!
Always good to read those Roadmaps.
- Has Genode's development during 2024 been in your interest?
- Or do you find important aspects neglected?
- How was your practical experience with Genode in 2024?
2024 was both a big year for my Genode projects but also kind of failure. I did a quite succesful demo scenario on i.MX8, using every little cpu cycle that was available.
I also continued with my RockChip port .. enabled it to start on RK3399 up to displaying graphics on Pinebook Pro.
The projects that I failed with: Back in 2023 I had a very ambigous plan for a cross over system based on Genode framework AND RISC OS. This wasn't realised in 2023 and not in 2024 either.
Generic EHCI driver. This was the last thing I did start on. I somehow lost motivation,, I started with initing EHCI and could see that I got interrupts.
- Which directions would you regard as most exciting or pressing?
As a person that isn't a Sculpt user, most things passed by. But I appreciate all low level successes.
- What are your personal interests and plans for 2025?
EHCI. I can't get my stupid head around DDE drivers, and I really want a generic EHCI driver as it enables a lot. XHCI is also possible.
I want to realise my big plan from 2023. A very difficult project but is also quite rewarding. In my demo scenario in 2024 I picked i.MX8 because it was a SoC that both RISC OS and Genode supported ( I did a very quick and dirty bringup of RISC OS for MNT Reform some year/s ago). For the grand project I would like to find a way to do abstraction against Genode. Streamlining RISC OS HAL to Genode. Not easy but also not impossible. I think that the platform will be RK3588 as this is a very powerfull Soc and also to be available with MNT Reform. This also presents some new things for Genode.. The SoC has cores numbered 0 to 3 for the boot cpu .. but if you want to use the big cpu as your main one the current base-hw will not work. I would be happy to rethink how this should be done in Genode.
My Genode inititaives ( demo and Rockchip ) are on GitHub: https://github.com/mickenx
I wish you all a great 2025!
Michael Grunditz
Hi Michael,
thanks a lot for responding. It's always great to see what you - who are using Genode in the most creative ways - are up to.
Generic EHCI driver. This was the last thing I did start on. I somehow lost motivation,, I started with initing EHCI and could see that I got interrupts. [...] EHCI. I can't get my stupid head around DDE drivers, and I really want a generic EHCI driver as it enables a lot. XHCI is also possible.
DDE-Linux is fantastic for our team to support a wide range of hardware on par with Linux. But from an enthusiast point of view, it can be rather daunting. If I was in your shoes, I'd would probably also prefer to skip those layers of complexity and go directly to the hardware. It is more fun and rewarding. There is certainly room for HCD drivers beyond a DDE-Linux-based driver. Stefan has tempting ideas for splitting the host-controller driver(s) from the USB driver into separate (client) components, making them pluggable. Once these ideas come to fruition, the integration of custom host-controller drivers will become a natural option.
I want to realise my big plan from 2023. A very difficult project but is also quite rewarding. In my demo scenario in 2024 I picked i.MX8 because it was a SoC that both RISC OS and Genode supported ( I did a very quick and dirty bringup of RISC OS for MNT Reform some year/s ago). For the grand project I would like to find a way to do abstraction against Genode. Streamlining RISC OS HAL to Genode. Not easy but also not impossible. I think that the platform will be RK3588 as this is a very powerfull Soc and also to be available with MNT Reform. This also presents some new things for Genode.. The SoC has cores numbered 0 to 3 for the boot cpu .. but if you want to use the big cpu as your main one the current base-hw will not work. I would be happy to rethink how this should be done in Genode.
Thanks for sharing those plans.
BTW, just a few days ago, MNT started a new crowdfunding campaign for the Reform Next laptop [1], which will happen to use the RK3588 SoC by default.
[1] https://www.crowdsupply.com/mnt/mnt-reform-next
All the best
Norman
Howdy Norman and fellow Genodians
Starting off on a honest footing, I'd have to summarize 2024 acknowledging that my "engine" is chronically under-powered for the goals I set to myself each year. In fact those last few months I was struggling when just keeping up with new Genode releases (red queen syndrom, run to stay still), let alone making progress in my code, let alone learning more about Genode and Goa (so as to possibly publish my apps as packages, be they user convenience apps or developer tools) and so on... So I'll refrain from setting goals to myself altogether this time, will just mention a hint or two. "Worst" thing that can happen, next year I end up being actually high-energy and productive and in need of improvising a roadmap on-the-fly *g*.
But -- I still met one of my goals for 2024 though, scoring a solid "yes" on the question "can I use h-on-Genode with Falkon on all my computers". I checked that again with the recent package upgrades prompted by an ABI change: I had to update all related computers in this house, and verified yet again that I can boot up any of them with my USB thumbdrive in seconds, click 'Download' on the relevant package(s), and run Falkon once the download is complete. Cannot ask for more as far as that (specific/narrow) functional aspect is concerned.
For next year now -- last month I started elaborating a scheme whereby I'd implement some sort of Genode-based NAS (Network Attached Storage) for this household, but looking around it seems the entry model iMX SoC goes for half a grand, so that'll have to wait until the prices go down massively. Or maybe I'll get a cheap rasp. Pi instead (hopefully they are still cheap these days? they retailed for $35 when I first heard of them eons ago) and use Linux initially.
The most likely thing to occur, and soon, is setting up my Debian laptop with an NFS server (done) and my 'main' developer box as an NFS client (in progress), which should allow me to edit files the way I'm used to, removing a point of friction when working on Genode. Then we'll see if my Genode productivity rises a bit.
As to more distant goals, I'm still interested in my (technically "my wife's" ^^) PinePhone. Now that I got it to run Sculpt OS, after finding a micro-SD-card that actually works with it, and that I'm a Debian user (sort of), there's nothing preventing me any more from doing custom Sculpt OS builds, to try and optimize the system for 2 GB mem usage and so on, and return to testing the basics (phone calls) some more etc.
**
As always, kudos to you Norman for having the patience and self-discipline to keep the Genode code base tidy and refactored and trim the technical debt. I wish I could be as efficient in my own code.
- Has Genode's development during 2024 been in your interest?
- Or do you find important aspects neglected?
- How was your practical experience with Genode in 2024?
The aspect that affects me most is the mixer transition, which occured many months ago already but which I'm only now near to tackling (hopefully in early January).
Keeping up to date with Genode releases is now a well-oiled routine for me, and this year was no exception and even improved a bit thanks to Debian Linux.
- Which directions would you regard as most exciting or pressing?
- What are your personal interests and plans for 2025?
Optimizations in the FS stack are something I keep an eye on. I'll never allow myself to say "pressing!" as I know it's a huge endeavour, and one should not rush to optimization before everything is clean and refactored. That said, I think I will be able to help a bit with those in terms of Q.A., seeing as my VFS use-cases are out of the beaten path a little and thus extend the coverage and verification, and given that my project's test suite tends to "push" Genode's vfs a little, in terms of coverage (corner cases) ad in terms of being demanding performance-wise, so as to reveal things of interest in that area.
Cedric
Hi Cedric,
reading about your experience reports and plans is always a joy! Thank you for participating.
But -- I still met one of my goals for 2024 though, scoring a solid "yes" on the question "can I use h-on-Genode with Falkon on all my computers". I checked that again with the recent package upgrades prompted by an ABI change: I had to update all related computers in this house, and verified yet again that I can boot up any of them with my USB thumbdrive in seconds, click 'Download' on the relevant package(s), and run Falkon once the download is complete. Cannot ask for more as far as that (specific/narrow) functional aspect is concerned.
Reading that makes me very happy. It's gratifying to see our work paying off and being recognized.
The aspect that affects me most is the mixer transition, which occured many months ago already but which I'm only now near to tackling (hopefully in early January).
Since we introduced the new audio interfaces about one year ago, we gathered quite a bit of practical experience with using the new mixer, which revealed one point I wish to refine: To make the mixer robust against overflow/underflow issues, it adjusts the sample rate per client dynamically according to the client's behavior. This works well for clients that work periodically enough. But we figured that periodic behavior is not a given for all audio clients. Insufficiently periodic clients can exhibit audible droning artifacts. This is not always the client's fault but may be caused by sporadic CPU load induced by high-priority components. In cases like this, it would make sense to move the time-window allocation from the mixer to the client side and thereby weaken the requirement of periodicity.
Over the course of 2025, I'd like to try this out. Your feedback and validation would be very valuable for me.
Optimizations in the FS stack are something I keep an eye on. I'll never allow myself to say "pressing!" as I know it's a huge endeavour, and one should not rush to optimization before everything is clean and refactored. That said, I think I will be able to help a bit with those in terms of Q.A., seeing as my VFS use-cases are out of the beaten path a little and thus extend the coverage and verification, and given that my project's test suite tends to "push" Genode's vfs a little, in terms of coverage (corner cases) ad in terms of being demanding performance-wise, so as to reveal things of interest in that area.
Thank you for the offer. Your past feedback about the VFS was super helpful. So I'm happy about your willingness to help in the Q/A department for the changes to come. :-)
Cheers Norman
Hello Genodians,
as I don't want to miss out our annual roadmap discussion, I contribute my share in the following.
Reflections of 2024
While we addressed some new devices (e.g., MNT Pocket Reform) and platforms (i.MX 8M Mini/Plus) in 2024, we merely conducted baby steps to gear up Sculpt for daily use on PC notebooks. Though, the IOMMU work seems quite fit for this purpose, we also identified other shortcomings (ACPI, CPU bring-up, TSC calibration) that have to be addressed to achieve broad compatibility with recent devices. Speaking of ACPI, I learned much during my endeavours of boot-time ACPI discovery but got stuck in the middle of a proof of concept implementation due to the complexity of the topic and other obligations. On the other hand, I'm quite proud of our general support for touch and pointer-based device handling and the extensive multi-monitor support.
Propositions for 2025
Beside the obligatory tying up of lose ends (e.g., VirtualBox multi-monitor integration), I have the following topics on my personal agenda.
First, support for IPv6 in our network infrastructure is long overdue and poses potential to become a main topic for 2025. As NIC router is IPv4-only, I see an IPv6-capable pendant that implements all other mandatory protocols robust NDP proxying as an integral element of this work. Further, dual-stack support must be ensured, which means simultaneous v4/v6 on the routing level as well as IPv6 support in lxip/lwip.
Moreover, I'd love to integrate Goa and Goa-based ports into our daily development workflows as porting software with this tool is much easier and straight-forward. The first element is the port of uacme for use on Genodians.org.
Finally, I'd like to continue my ACPI discovery work and benefit from the potential to address PC platform issues early at boot time.
Genode at the end of 2025
In 12 months, I hope to use Sculpt on base-hw for my own and other recent notebooks (Meteor Lake or even Lunar Lake) to its full potential (incl. IPv6 ;-).
Best regards
Hello everyone,
all through the year 2024 I was mainly in maintenance mode. I was heavily involved in the upgrade of our Linux base version used in dde_linux to 6.6. This involved all platforms but the PinePhone. I also helped with the enablement of the MNT Pocket Reform (USB-host/display drivers).
Additionally, I spent a lot of time debugging for various releases or simply to identify and fix bugs. May it be problems in Webkit, our IP stacks, general driver issues, or regressions.
On the 3D side I did not reach all my goals for 2024, namely enable 3D support for Intel Alder Lake and to build Mesa as a Goa project. While I was able to update Mesa to a 24 version with Alder Lake support, I started to add but did not finish Meson support (a requirement for Mesa) in Goa in order to convert Mesa into a Goa project.
For 2025 I want to join Christian's effort regarding IPv6 for the IP-stack/VFS side while also gathering more knowledge about IPv6 internals in general. Also I would like to have a look into support for newer Intel generations of our GPU multiplexer/driver.
Kind regards,
Sebastian
Hello everyone,
for past few years I refrained myself from declaring anything on the yearly roadmap discussions, as I did not believe that I'll be able to spend substantial amount of time for Genode development. I'm uncertain about 2025 too, but I can at least share my hopes.
Review of 2024
From my perspective, the two biggest breakthroughs had been suspend/resume on x86 (added in May) and multi-monitor support (added in October).
I fully agree about those topics being the most important achievements in Genode development last year. Especially (what I already expressed somewhere) multi monitor support was the crucial feature for me and I'm using it every day now.
Regarding suspend/resume I wasn't able to resume with virtual machines running when I last tested it, so I currently restrain myself from using it, but I'm waiting for it to be fully finished.
My main achievement for last year is the complete switch to Sculpt as my main OS on my personal computer (laptop). Since I managed to configure "native" Linux in a VM on Sculpt about 2 months ago, I did not boot it as first OS - only inside Sculpt.
My plans for 2025
I think, as a user, I can declare myself as a tester of Sculpt. I had it running with uptime for about three weeks till today. Unfortunately I was forced to reboot due to some strange global performance issues. I can try to help in the future in diagnosing such issues by providing some data in case there is a need for it.
For immediate plans I will try to invest time in vnc client as I use it for accessing my development machine. Two aspects are currently most pressing:
* understanding configuration and internals of keyboard handling (enter key is repeated in an uncontrolled way, modifiers handling is blocking some shortcuts like Ctrl+Shif+C for copy, somehow I was able to get into a state when Caps Lock is inverted between Sculpt and remote desktop, etc.)
* analyze performance - sometimes redrawing of remote screen (size of 2 full hd monitors) takes few seconds in a LAN, so it is far from convenient.
For other tasks I'd like to be able to go back to my unfinished, abandoned do to lack of time activities like support for Raspberry Pi devices and exploring improvements for Genode development. Those ideas are unfortunately more wishes than plans.
Best regards
Tomasz Gajewski
Hello Tomasz,
thank you for your comments about the road map.
My main achievement for last year is the complete switch to Sculpt as my main OS on my personal computer (laptop). Since I managed to configure "native" Linux in a VM on Sculpt about 2 months ago, I did not boot it as first OS - only inside Sculpt.
That's reassuring feedback and wonderful to know!
I think, as a user, I can declare myself as a tester of Sculpt. I had it running with uptime for about three weeks till today. Unfortunately I was forced to reboot due to some strange global performance issues. I can try to help in the future in diagnosing such issues by providing some data in case there is a need for it.
I'd appreciate that a lot because testing over long periods is still a somewhat blind spot. E.g. in my case, I'm powering off my laptop each evening and rebooting it in the morning. So I won't casually hit such issues that show up only after weeks.
The next time you observe such an anomaly, it would be good to have a look at the top tool or to enable the trace-logger option to observe the CPU utilization, hoping for clues. It would also be interesting to see if the issue disappears when restarting the VM.
For immediate plans I will try to invest time in vnc client as I use it for accessing my development machine. Two aspects are currently most pressing:
* understanding configuration and internals of keyboard handling (enter key is repeated in an uncontrolled way, modifiers handling is blocking some shortcuts like Ctrl+Shif+C for copy, somehow I was able to get into a state when Caps Lock is inverted between Sculpt and remote desktop, etc.)
* analyze performance - sometimes redrawing of remote screen (size of 2 full hd monitors) takes few seconds in a LAN, so it is far from convenient.
For other tasks I'd like to be able to go back to my unfinished, abandoned do to lack of time activities like support for Raspberry Pi devices and exploring improvements for Genode development. Those ideas are unfortunately more wishes than plans.
Thanks for sharing. I think that the Raspberry Pi remains an interesting target from the community perspective, especially compared to the rather expensive i.MX hardware.
Cheers Norman
Hi,
I'm sending info which I collected/remember when performance issue mentioned in Roadmap discussion happened.
I think, as a user, I can declare myself as a tester of Sculpt. I had it running with uptime for about three weeks till today. Unfortunately I was forced to reboot due to some strange global performance issues. I can try to help in the future in diagnosing such issues by providing some data in case there is a need for it.
The next time you observe such an anomaly, it would be good to have a look at the top tool or to enable the trace-logger option to observe the CPU utilization, hoping for clues.
I have made a photo of top from that episode. Let me know if next time you'd prefer to get different view to get different set of information.
top
It would also be interesting to see if the issue disappears when restarting the VM.
It did not help. I have tried that.
Before stopping virtual machines working in system shell was hard because even listing files took seconds. When I stopped virtual machines the situation improved but as soon as I tried to start them again, system has become unresponsive again. Then I rebooted.
I also have a copy of /report/log from that time, but I don't see anything suspicious there. By the way it would be useful if there was some kind of timestamp with log (it doesn't have to be a real time). Trying to correlate information from log with the performed actions is hard if you do not have any information about "age" of each log.
I don't expect much, but hopefully it will give you some useful information - even if only ideas how to improve such process of gathering information for similar events in the future.
Regards
Tomasz
It seems that enforcing text format caused the image to be removed. Here's the link to it.
Tomasz Gajewski
Hi Tomasz,
It would also be interesting to see if the issue disappears when restarting the VM.
It did not help. I have tried that.
Before stopping virtual machines working in system shell was hard because even listing files took seconds. When I stopped virtual machines the situation improved but as soon as I tried to start them again, system has become unresponsive again. Then I rebooted.
this reminds me of a situation I sporadically encountered on my Gen12 Framework laptop. Once heavily stressing the system by a large compile in "high-performance" mode, some kind of overheat protection of the firmware kicks in and forcibly throttles all cores to 400 Mhz.
Interestingly, the forced throttling is retained long after all temperatures have cooled down to less than 50 degrees. Usually, the situation recovers after 1/4 hour. In one case, however, the situation wouldn't even recover after reboot, even on the day after. Only detaching and re-attaching the battery (can be done in the BIOS menu) fixed it. It goes without saying that I keep using the "balanced" mode since then.
The effects of the firmware can be nicely observed using Alex' MSR GUI tool. I leave it running at all times.
I also have a copy of /report/log from that time, but I don't see anything suspicious there. By the way it would be useful if there was some kind of timestamp with log (it doesn't have to be a real time). Trying to correlate information from log with the performed actions is hard if you do not have any information about "age" of each log.
Noted [1].
[1] https://github.com/genodelabs/genode/issues/5422
Cheers Norman
On 15.01.2025 11:18, Norman Feske wrote:
this reminds me of a situation I sporadically encountered on my Gen12 Framework laptop. Once heavily stressing the system by a large compile in "high-performance" mode, some kind of overheat protection of the firmware kicks in and forcibly throttles all cores to 400 Mhz.
Interestingly, the forced throttling is retained long after all temperatures have cooled down to less than 50 degrees. Usually, the situation recovers after 1/4 hour. In one case, however, the situation wouldn't even recover after reboot, even on the day after. Only detaching and re-attaching the battery (can be done in the BIOS menu) fixed it. It goes without saying that I keep using the "balanced" mode since then.
The effects of the firmware can be nicely observed using Alex' MSR GUI tool. I leave it running at all times.
I tried to run it but failed (used alex-ab/pkg/msr_gui/2024-10-30).
Initially it complained about menu_view expected to get more ram and caps than limits for runtime - although I don't know if it is required, I have extended limits in runtime element to silence them.
It has also reported:
[runtime -> msr_gui -> msr] ^[[31mError: - CPU or used kernel misses MSR access support^[[0m [runtime -> msr_gui -> msr] ^[[31mError: - and/or missing 'managing_system' configuration^[[0m
For this I have tried to add `managing_system="yes"` to runtime element, but it did not change anything. I'm not sure if it is about MSR or managing_system (I have Lenovo T460p). It would be great if you could suggest something to fix it or check.
I also have a copy of /report/log from that time, but I don't see anything suspicious there. By the way it would be useful if there was some kind of timestamp with log (it doesn't have to be a real time). Trying to correlate information from log with the performed actions is hard if you do not have any information about "age" of each log.
Noted [1].
Thank you very much.
Tomasz Gajewski
Hi Tomasz,
On 15.01.25 20:36, Tomasz Gajewski wrote:
On 15.01.2025 11:18, Norman Feske wrote:
this reminds me of a situation I sporadically encountered on my Gen12 Framework laptop. Once heavily stressing the system by a large compile in "high-performance" mode, some kind of overheat protection of the firmware kicks in and forcibly throttles all cores to 400 Mhz.
Interestingly, the forced throttling is retained long after all temperatures have cooled down to less than 50 degrees. Usually, the situation recovers after 1/4 hour. In one case, however, the situation wouldn't even recover after reboot, even on the day after. Only detaching and re-attaching the battery (can be done in the BIOS menu) fixed it. It goes without saying that I keep using the "balanced" mode since then.
The effects of the firmware can be nicely observed using Alex' MSR GUI tool. I leave it running at all times.
I tried to run it but failed (used alex-ab/pkg/msr_gui/2024-10-30).
Initially it complained about menu_view expected to get more ram and caps than limits for runtime - although I don't know if it is required, I have extended limits in runtime element to silence them.
It has also reported:
[runtime -> msr_gui -> msr] ^[[31mError: - CPU or used kernel misses MSR access support^[[0m [runtime -> msr_gui -> msr] ^[[31mError: - and/or missing 'managing_system' configuration^[[0m
For this I have tried to add `managing_system="yes"` to runtime element, but it did not change anything. I'm not sure if it is about MSR or managing_system (I have Lenovo T460p). It would be great if you could suggest something to fix it or check.
You need to check the 'Resource assignment ...' -> 'System control' box when installing msr_gui via the GUI. I have not managed to find a way to configure this in runtime/deploy for myself.
Cheers,
Sebastian
On 15.01.2025 21:44, Sebastian Sumpf wrote:
You need to check the 'Resource assignment ...' -> 'System control' box when installing msr_gui via the GUI. I have not managed to find a way to configure this in runtime/deploy for myself.
Thank you very much Sebastian. I completely forgot that I can set it there. Now it works.
Tomasz
Hello,
in 2024 I spent most of my time on the Sculpt on-target debugging topic and the Qt6 update.
I like how the debugging solution turned out so far with the simple Genode components which automatically download the debug packages in the background and dynamically create symbolic links to the symbol files of the monitored components for GDB by watching and evaluating the Sculpt runtime configuration.
The Qt6 update was a bit challenging with the Qt build system switch from qmake to CMake, but the essential Qt6 modules are working now and an updated Falkon browser can load simple web pages like genodians.org already, but unfortunately introduced a new problem with an unclickable scroll bar which I'm currently debugging and also still needs more of the Qt5WebEngine patches for Genode adapted to Qt6 for more complex pages with JavaScript or multimedia.
So, for 2025 I'm planning to continue working on the Qt6 Falkon and Morph browsers and then it will probably be time for another Genode tool chain update. Apart from that I'm also interested in the topic of building Genode and Genode components natively on Genode, which Norman mentioned, and would help working on that.
Christian
Hi Christian,
I like how the debugging solution turned out so far with the simple Genode components which automatically download the debug packages in the background and dynamically create symbolic links to the symbol files of the monitored components for GDB by watching and evaluating the Sculpt runtime configuration.
I wholeheartedly agree! All the individual steps where so carefully planned and executed. It was wonderful watching how these foundations happened to also inspire Goa's recent debugging support, leveraging the downloadable symbols and the monitor component [1] to great effect.
[1] https://genodians.org/jschlatow/2024-07-31-goa-gdb
Now, what's admittedly left is to move our regular work flows more and more towards this powerful tooling.
So, for 2025 I'm planning to continue working on the Qt6 Falkon and Morph browsers and then it will probably be time for another Genode tool chain update. Apart from that I'm also interested in the topic of building Genode and Genode components natively on Genode, which Norman mentioned, and would help working on that.
That sounds like a solid plan!
I'm extremely grateful for your steady hand in the tool-chain topic.
Regarding your last point, I definitely plan to (re-)attend the problem of tracing of short-lived activities, which somewhat fizzled out last time we looked at it. Once this instrument is in place, chances will be good that we can jointly uncover the bottlenecks in the libc/vfs.
Cheers Norman
Hi,
in 2024 I was mostly occupied with lending a helping hand with DDE Linux (“Yes, the same procedure as every year, James!”), updating and adding new drivers on various platforms. Apart from that there was the usual debugging and fixing of nagging issue.
I reckon 2025 is going to go in a similar direction but at least two topics come to mind I plan spending time on:
❶ I would like to retire VBox for my personal usage and with the great groundwork Alex did for Seoul that is a realistic goal.
(Most OSes I would like to use in a VM by now all support VirtIO devices and are not supported by the guest-additions anyway.)
Apart from that looking into things like libkrun, i.e. partially isolated environments using virtualization, and how we could integrate such a solution is tempting but probably too extensive.
❷ I would like to have a more debug-oriented sculpt.img that eases diagnosing problems when encountering unknown or not anticipated hardware (like containing multiple different bootable configurations excercising different aspects).
(This falls somewhat in line with using 'boot_fb' for bootstrapping purposes and starting the appropriate driver component afterwards as was already briefly discussed elsewhere.)
Best regards Josef
Hello,
looking back at 2024 it mainly came as suspected in my previous road map mail. The suspend/resume work kept me busy until a first experimental version got added to Sculpt OS during the first part of the year. Later on, various customer related optimizing work took the rest of the first part. In the second part of the year, I mostly spent the time with the intel/display driver, on the one hand the upgrade to a newer Linux version and all the hazzle in getting all notebooks generations running again and on the second hand the adding of the multi-head support of the driver to Genode upstream.
My first year of Vbox deprivation went quite well for me, especially after adding the USB host model to Seoul and removing the "big" VMM lock in the Seoul frontend in the beginning of the year 2024. Even so I'm fine with the current state for my personal daily use, it became clear during discussions with others, that more "convenient" VMM models may help other users. Thanks to an intensive pre-xmas-one-weekend-day session with Josef, we have prototypes for virtio_net (Josef) and virtio_fs (me, aka get shared folder support), which waits to be finished as soon as time permits. Also, if I can effort it, I plan looking into Tianocore and how to add this to Seoul for UEFI boot support.
Additionally, I bought last year several network cards for my desktop system in order to play with SR-IOV and pass through into VMs on Genode. From my perspective, the feature is overdue and I would like to change this.
Another idea/topic, which may be worthwhile to play with, is, to move the intel/display driver out of the basic Sculpt image and load it as kind of on-demand second stage driver (as separate downloadable package). In the beginning, either the vesa or boot_fb driver can be used and should be sufficient. Later on, the Sculpt user may start resp. configure to use the intel/display driver and can make the change persistent in its configuration for the next boot. This would ease/pave the way for easier deployment of other display drivers like for NVIDIA or AMD. Well, and of course, same procedure as every year, I would like to pick up the work of Josef of amdgpu_fp_drv to get it up and running ...
Cheers,
Alex.
Hi Alex,
Another idea/topic, which may be worthwhile to play with, is, to move the intel/display driver out of the basic Sculpt image and load it as kind of on-demand second stage driver (as separate downloadable package). In the beginning, either the vesa or boot_fb driver can be used and should be sufficient. Later on, the Sculpt user may start resp. configure to use the intel/display driver and can make the change persistent in its configuration for the next boot. This would ease/pave the way for easier deployment of other display drivers like for NVIDIA or AMD. Well, and of course, same procedure as every year, I would like to pick up the work of Josef of amdgpu_fp_drv to get it up and running ...
this is a tempting direction, slimming down the Sculpt base image while becoming more open to options other than Intel and decoupling driver updates from the Sculpt image. We should definitely go for it. The most tricky part is probably the handover of the display from one driver to another. Wondering, can this be achieved without much flickering? Let's find out!
Regarding the Seoul-related topics championed by you and Josef, it is probably best to reserve enough time to make satisfactory progress but not frame these activities as official direction of Genode. Such work is enjoyed most without product responsibilities. Do you share my view?
Cheers Norman
Hello,
At Hack'n'Hike I was impressed by what all the new features of Sculpt / Goa 24.04 made possible. We were able to play Diablo on top of Sculpt :-).
During my job working with the Genode framework I helped debug some strange errors and tested the fixes provided by Genodelabs.
On the personal side, I unfortunately didn't finish a single project I had on my Roadmap for 2024.
For 2025 I still want to continue the projects from the previous year: - Use Sculpt as my daily driver at work - integrate Intel IGC support in to pc_nic (this compiles and runs, but no packets received) - VFS plugin for I2C to replace the I2c session
Regards, Pirmin
Hello everyone,
thanks for all your contributions to the upcoming roadmap so far. And I wish you a happy new year 2025!
Looking back at last years roadmap discussion and the actual work I was doing that year, I hesitate to do any further proposals. Most of the ideas that I mentioned last time, which finally entered the roadmap, were not realized by me, or others, like the plugable USB-Host driver, multi-component E-mail client, easy to bootstrap Linux VMs on ARM, or the re-newal of the base-hw scheduler. Although the last point was started enthusiastically by Johannes and me, the implementation finally got superseded by maintainance, support issues, and lots of driver updates and driver portings. Hereby, as a highlight and with the help of my colleagues I could enable my new Framework 13 laptop (Meteorlake inside) as my daily work driver.
Considering the already mentioned directions, I like to strengthen Norman's proposal to concentrate on performance and optimization to enable other native dynamic workloads on Sculpt. Personally, I like to push base-hw's performance (e.g. scheduler work), remove known shortcomings, and enable it on newer hardware (e.g. Meteorlake). Having the hardware-independent USB multiplexer is still on my wish-list to push the dynamic hardware restart-abilities resp. suspend/resume potential. I also would like to take the last step of re-using one USB-device by different drivers, e.g. a USB headset with audio and HID functionality. Although, everything is in place to do so, final steps in the USB clients have to be taken. But I realize that I start to itemize ambitious goals again that probably get pushed aside by other needs, therefore I better stop now ;-).
Best regards Stefan
Hello everyone,
I wish you a pleasant and exciting 2025!
Reflecting on 2024 evokes mixed feelings:
Genode 24.05 incorporated support for Intel's Virtual-Machine Extensions (VMX) and as envisioned in the road map we managed to release a first Sculpt PC variant on the base-hw kernel. However, we didn't get base-hw to the point of widespread use in Sculpt on PCs.
On the Rust side of things, it was very gratifying to see the ease with which our friends Robin and Daniel managed to get Devilution transpiled to Rust to work on Genode on the Pinephone with just tiny changes to our Rust support in Goa at our annual Hack'n'Hike event. I managed to find a new approach to making Rust play nice with Genode in the face of binary incompatibility[1] and made progress at implementing async IO support in our libc port, but fell short of getting async Rust runtimes to work as a foundation for a potential Rust component in the envisioned multi-component show case.
Ultimately, I'm happy to see Sculpt OS 24.10 run smoothly on my development machine with the countless improvements across the system and the new multi-monitor support and improved resource accounting supporting my high-resolution setup out of the box. As a developer, Genode's enhanced debugging capabilities and the Goa SDK with its remote target support were another source of joy.
For 2025, my plan is to soon wrap up ongoing refactoring work in base-hw and get base-hw ready to run on a larger range of machines.
Over the year I would like to make some more improvements to base-hw's virtualization support and I hope to find time to get our Rust port ready for common async frameworks. Besides that, I am open to see where the varying interests of our customers take us, may it be enhancing base-hw, building more complex software scenarios on Genode OS or something else entirely.
Kind regards,
Ben
[1] https://genodians.org/atopia/2024-08-27-building-rust-with-a-custom-profile
Hi everyone,
let me join in and contribute my share to the roadmap discussion...
Review of 2024
Last year, I took off towards improving Sculpt OS usability by adding utility GUI applications and documenting their development. After finishing the lvgl-based system-info application, however, I distracted myself with a quest for a new scheduling concept for base-hw. As the year passed, it turned out that the Goa SDK endlessly sparks new ideas that let me change course a bit towards developer-friendliness. As a result, I was able to establish a solution for using Sculpt as a remote test and debugging target with Goa. I am joyful to see the Goa testbed preset being integrated into our official Sculpt images.
As planned, I was able to assemble the first revision of the "Genode Applications" book. I would have liked to include a Goa tutorial for from-scratch Qt application development as well, yet it turned out that I am too much of a Qt noob for this to be worth the time and effort. Instead, I started an explorative journey on integrating devtool sandboxing into the Goa SDK and replacing gnupg with sequoia. This involved substantial refactoring of Goa's code base and is therefore still living on a topic branch.
On the devices front, I wanted to make use of the ZimaBlade single-board server and the StarLite tablet. Unfortunately, I haven't touched the former ever since and did not find the time to enable the touchscreen on the latter.
Outside the realm of my own topics, my most-enjoyed features of the year are the on-target debugging and the multi-monitor support.
My plans for 2025
Currently, I consider Goa and the StarLite tablet my most inspiring drivers. I picture myself jauntily using the StarLite with base-hw for Sculpt-native web-browsing, PDF viewing, YouTube and maybe Goa by the end of the year. For this goal, I gladly join Norman on the journey towards a file-management solution for Sculpt (e.g. for opening downloaded PDF files in mupdf). Moreover, I will be happy to accompany Stefan on the base-hw scheduler work.
With respect to Goa, I would like to seal the loose end that I left in form of the sandboxing and sequoia integration. Moreover, I plan to write a libslirp-based alternative to our linux Nic driver in order to relieve Goa users of the burden to set up tap devices.
Cheers Johannes
Greetings Fellow Sculptors,
The annual Roadmap discussion is always one of my favorite times of the year. It is really enlightening to hear from so many different voices - from Genode Labs insiders, to commercial customers, to hobbyists (and everything in-between). Thanks for fostering such a delightful tradition!
I don't have any earth-shaking ideas to share, but the ideas that others have shared sound great to me!
As for my plans for the year, anyone who is disappointed by their own progress last year should look at me, to feel better about themselves. ;^) But hope springs eternal, and here is what I will try to accomplish:
- Move to Sculpt as my daily driver OS. (This would have already happened, but I somehow screwed up my HD partitioning, which I will soon rectify.)
- Get more familiar with Goa, and publishing components.
- Experiment with native APIs, especially Nitpicker and Dialog. (Eventually, I would love to also explore the VFS.)
- Keep tinkering with IDE integration, for Goa and general development. (There are some interesting possibilities here.)
Given all that, the only thing I might ask of the Genode team is more documentation on the Native APIs. I'll be exploring the examples, but I need all the help I can get. :^)
Happy Sculpting, Everyone!
John J. Karcher devuser@alternateapproach.com
Hi John,
thanks for chiming in! As always, your feedback is highly encouraging.
- Keep tinkering with IDE integration, for Goa and general development.
(There are some interesting possibilities here.)
That's very good because this area is otherwise pretty much neglected so far.
Given all that, the only thing I might ask of the Genode team is more documentation on the Native APIs. I'll be exploring the examples, but I need all the help I can get. :^)
At the current time, the native APIs solely serve the purpose of Genode and Sculpt, but are not geared for a wider adoption by application software built atop.
This distinction is important. To illustrate the fine line, the dialog API does not even try to address multi-language support. This is fine for the narrow scope of Sculpt's administrative UI and tools created decidedly for English-speaking Sculpt power users. But it would fall flat on the face for catering consumers. The API is a means to a specific end, not an asset worth recommending at large.
Hence, the barrier of entry is not entirely unintended. Even though I'm delighted about your interest in the native APIs, I hesitate to put them into the spotlight to avoid raising wrong expectations.
Cheers Norman
Dear Norman and fellow Genodians,
After posting my personal goals for 2025, here is the response from Gapfruit's perspective.
2024 has been an exciting year for Gapfruit.
In 2024, we collaborated with Genode Labs to enable the BSP for the powerful i.MX8MP SoC from NXP. We continued our work on the TPM stack by designing different Genode components that act as pluggable building blocks to improve the guarantees of trustworthiness even when considering physical attacks. One aspect of this work was to enable the TPM2-TSS stack, which depends on OpenSSL > 3.0. Therefore, we contributed OpenSSL 3 to Genodelabs (PR pending). We further improved our test infrastructure [1].
As with every year, we at Gapfruit eagerly follow the sharing of ambitions and goals of other Genode enthusiasts. This year is no different. What sparked our interest was the discussion Norman started regarding offloading apps out of VMs to pure Genode components. When we discuss potential migration paths with our customers from legacy systems to a more resilient and trustworthy future, we strive to find solutions that don't require VMs. We are willing to collaborate towards any efforts that streamline the building and running of existing code bases on top of Genode systems - namely improving Goa, libc, and vfs. Speaking of Goa, the work of Johannes regarding remote debugging via the Goa testbed is exceptionally cool, and we are very interested in helping get Rust async support mentioned by Benjamin. Also, the topic of IDE integration that John mentioned sparked our interest.
Our challenges in 2025 will be to support more hardware from different hardware vendors and work with various external customers and partners that build on our product.
We see a rising need to deal with different API and ABI versions for the latter challenge, especially when our partners write and deploy their applications and subsystems.
Our plans for 2025 can be summarized as follows:
- We plan to create a Gapfruit Community Git repository containing various components, starting with the TPM stack. - We plan to make our measured boot and trusted boot implementation available through the Gapfruit Community repos or by contribution once they have reached maturity. - We accompany a master's thesis at ETH Zurich that aims to introduce fuzzy testing on the session level to Genode.
Cheers, The Gapfurit Team
[1] http://genodians.org/trimpim/2024-09-25-testing-device_control
Hello Pirmin,
happy to read your positive review of the past year. I already noticed with delight that Alice will present the TPM work at FOSDEM [1]. Very cool!
[1] https://fosdem.org/2025/schedule/event/fosdem-2025-4140-trusted-boot-with-th...
What sparked our interest was the discussion Norman started regarding offloading apps out of VMs to pure Genode components. When we discuss potential migration paths with our customers from legacy systems to a more resilient and trustworthy future, we strive to find solutions that don't require VMs.
That's all the better. It sounds perfect that our goals are so nicely aligned. From the feedback so far, I sense that the focus on rigidity, clarity, and performance resonates quite well with the community at large. So this will probably become our overarching theme for 2025.
Should me manage to bring the performance of native dynamic workloads (e.g. using the tool chain via Goa directly on Sculpt OS) to a practically enjoyable level, I would call the year a resounding success.
Our challenges in 2025 will be to support more hardware from different hardware vendors and work with various external customers and partners that build on our product.
Just out of curiosity, with more hardware, do refer to i.MX-based boards or are there other SoC families on your radar as well?
Our plans for 2025 can be summarized as follows:
- We plan to create a Gapfruit Community Git repository containing
various components, starting with the TPM stack.
- We plan to make our measured boot and trusted boot implementation
available through the Gapfruit Community repos or by contribution once they have reached maturity.
Thanks for sharing these plans. I very much appreciate these considerations of your team.
- We accompany a master's thesis at ETH Zurich that aims to introduce
fuzzy testing on the session level to Genode.
Given this background, the recent discussion on the forum [2] makes a lot of sense. Welcome smhm!
[2] https://genode.discourse.group/t/trying-to-compile-and-run-core-with-a-custo...
All the best for your team in 2025!
Norman
Hello Norman
Thank you for your encouraging words.
On 1/17/25 11:08, Norman Feske wrote:
That's all the better. It sounds perfect that our goals are so nicely aligned. From the feedback so far, I sense that the focus on rigidity, clarity, and performance resonates quite well with the community at large. So this will probably become our overarching theme for 2025.
This sounds excellent!
Should me manage to bring the performance of native dynamic workloads (e.g. using the tool chain via Goa directly on Sculpt OS) to a practically enjoyable level, I would call the year a resounding success.
Our challenges in 2025 will be to support more hardware from different hardware vendors and work with various external customers and partners that build on our product.
Just out of curiosity, with more hardware, do refer to i.MX-based boards or are there other SoC families on your radar as well?
We are focusing on the i.MX8-based boards. However, we are also considering enabling the i.MX93 SoC. Also, x86_64 is still on our Roadmap.
All the best for your team in 2025!
Thank you! Likewise!
Best, Pirmin
Hello everyone,
thanks a lot to everyone who has participated in the brainstorming. Today, I have updated Genode's official road-map page with a recollection of the past year and the plan for 2025.
https://genode.org/about/road-map
Looking forward to see how the year will play out. :-)
Cheers Norman
-
Alexander Boettcher -
Benjamin Lamowski -
Christian Helmuth -
Christian Prochaska -
Johannes Schlatow -
John J. Karcher -
Josef Söntgen -
Michael Grunditz -
Norman Feske -
Pirmin Duss -
Sebastian Sumpf -
Stefan Kalkowski -
Tomasz Gajewski -
ttcoder＠netcourrier.com