Hi Norman, yes you did answer, and how extensively so

I've added a solid link to your answer in my online notes (chiselapp/genode-book), for me to dig deeper in the future. For now it's a place-holder but maybe it could become a useful (actionable) summary for others to use in the future.

Truth be told, libav memory leaks do not seem to present a problem at this stage -- setting a "tight" memory quota and leaving my app running for a while, it does not run into the resource-request case, so the leaks are probably small or non-existant. So between that, and the options you described for handling the problem should it surface, I'd say I'm probably "covered" and won't worry about it.

FWIW, my Genode work will probably focus on drivers next, specifically AHCI and (more importantly) HDA. It's not sexy work (actually I kinda hate working on drivers) but not having HDA output on actual stations would be a deal breaker so I'll post more to the concerned ticket on github/genode in the future.

The stability situation on Haiku has improved, but I still want to keep working on this and make TTS/CC dual platform regardless (and commit more of my code to the public repo).

Cedric

I think all options should be covered by the dynamic init construction described above. The approach can naturally be extended by letting the child "report" additional (higher-level) information about its internal state. The manager may take those reports into account also. E.g., the Sculpt manager consumes the reports generated by drivers and part_block instances to find the Genode partition.