Hello Stefan,
thanks lot for sharing your view. I'm happy to read that the topics of last year were so much appreciated by you.
It is good to know the importance of i.MX8. This certainly reinforces our commitment to this SoC family. What you write about the deployment plans for 2024 sounds exciting!
Our pain points include stability problems with both available network stacks. We would also like to improve our in-house expertise in enabling new SoCs. Another issue worthy of further work would be the addition of resource trading to the fs_rom and cached_fs_rom components.
These are all valid and important points. Fortunately, Sebastian has already expressed his ambition give the network stacks the attention they deserve. At present, an lxIP stack based on the new DDE Linux is already under way.
I agree with you that the resource management of the ROM services should best undergo a revision. Maybe we can relieve your particular pain point by agreeing on an ROM-session interface change that would in principle enable you to implement a resource-management scheme that matches your requirements? E.g., one sensible change would be to let the `dataspace` call optionally return a `Session_resources` object instead of a dataspace capability (using the `Attempt` pattern), thereby telling the client that it is in need of the stated amount of RAM/caps. So the client can upgrade the session before issuing a `dataspace` call again. I think that this change is doable without much disruption. With this change in place, you could implement ROM services that let the client pay.
From my view, I would like to (sometime down the road) replace the cached_fs_rom by an implementation that leverages two features of Genode that are currently underutilized. First, Genode's on-demand page-fault handling could be used to fetch parts of ROM dataspaces on demand instead of loading each dataspace completely. This could speed up the start of components that rely on overly large ROMs (like QtWebEngine) while also allowing us to evict data, capping the RAM used for the cache. And second, the resource-balancing protocol (aka "balooning") of the parent interface could be put to good use for dedicating slack RAM for caching ROMs and freeing the RAM on resource pressure. However, as I wrote, I'm thinking of those ideas as being somewhat longer term.
Also, we would very much welcome any further work to make the debug monitor available on arm_v8a. Any advances in tooling for performance analysis of complex asynchronous components are also topics of interest.
That fits perfectly well with our - in particular Christian Prochaska's - present developments.
Thank you again for your participation in the road-map discussion.
Cheers Norman