Roadmap 2024

[Norman Feske]

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

-- 
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