Roadmap 2024

[Norman Feske]

Hi Cedrik,

On 2024-01-17 09:42, Cedric At TTS via users wrote:
> 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).

that's exactly my line of thinking. Personally, I encountered the 
limitation of the current implementation when using the MNT-Reform 
laptop with only 4 GiB of RAM. Once I start the Falkon browser, all the 
heavy-weight ROMs (Qt, WebEngine...) are loaded, inflating the depot_rom 
(cached_fs_rom) as expected. Now, when switching away from the browser 
(e.g., selecting another preset w/o Falkon), I want the depot_rom to 
deflate so that I can use the RAM otherwise. But this does not happen 
unless I do a full "un-use" "use" cycle of the Sculpt partition.

Both, the capping of RAM usage of depot_ram as well as the 
inflating/deflating can be realized with the lazy-loading / 
on-demand-eviction idea. Now, the devil of implementing it lies in the 
details (sensible eviction strategies, async fs access, granularity of 
I/O), for which reason I don't want to hasten it.

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

I love how you draw so many connections between our low-level ideas and 
your use cases when wearing the Haiku-hat (guessing you are a hat 
person?). :)

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