Roadmap 2024

[ttcoder at netcourrier.com]

A couple thoughts (hijacking?) re. this discussion:
> 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.

>From my vantage point, I find that idea (on-demand fetch) quite intriguing. If I
understand it correctly, it seems this concept would end up enriching the Genode API
with yet another "forte" (strong point), the same way that things like RM,
and the super modular vfs system, and many other things, empower us
when writing code for Genode.

If I put on my 'syst. integrator' hat, when crafting my system to run Falkon I found
myself wondering where to set the bar for the cached_fs_rom RAM quota, so that
it would be neither 'too little' nor 'too big/wasteful'. The prospect of just setting it to
a 'low' value like 200M and letting the Genode class handle where and when
to load/unload disk data to respond to read requests is enticing. (it could even
go the extra mile and allow the setting to be changeable dynamically, rather than
statically set once and for all at startup time).

(It would be like each app have their own "swap" that can be dialed up and down...
Except it would be completely different (grin), as there would be no write-back-to-disk
involved, only reading... but you get my drift : with that scheme, if an app has runaway
memory usage, it's free to use this on-demand cache and slow itself, without slowing
down the rest of the system ; it kind of meshes with the "each component have
their *own* vfs and their own ram disk" philosophy).

And now with my API user hat on, providing a generic system which would be an 'answer' to
things like mmap() or virtual-memory swapping used on other OSes but with the
usual Genode benefits (guaranteed protection against malicious client code etc) sounds quite good.

So, I guess,
something for the 2025 roadmap?, if it won't fit on the 2024 roadmap, would be my tentative encouragement ^^.

P.S. As a (quite marginal) secondary point, that hypothetical new infrastructure might
also help in my future/long term project to port the Hpkg package format to Genode
(i.e. the don't-extract-contents-to-disk-but-uncompress-on-the-fly-to-ram-instead
virtual FS concept that I've grown addicted to since the mid-2000s).

Cedric