Hello Norman,
Am Montag, 28. August 2017 12:05:38 CEST schrieb Norman Feske:
To overcome this limitation, I am currently investigating the use of a dynamic init instance as the host for subsystems. With this approach, the launcher merely generates configurations for the init instance and consumes reports generated by init.
With "init instance" and "by init" ... you mean here the "dynamic init instance" ?
yes. Actually, there is no difference between "init" and "dynamic init". It is the same program. The only difference is that the latter gets its configuration from a ROM service that produces new versions of the configuration at runtime. The first init is always static because it obtains its configuration from core's ROM service (as a boot module).
Ok, I read "4.6.3 Dynamic component reconfiguration at runtime" in the Genode documentation, but I forgot that the "root config" from core is read only.
I didn't get yet, the "full picture", how the launcer can be involved yet in the depot-deploy scenario, because depot_query start via depot_deploy the process (or subsystem?!) immediately or the depot_query can also be the launcher ?
There are two topics, which are somewhat intertwined. (1) creating subsystems out of packages stored in a depot, and (2) an interactive front end for generating init configurations. The depot-deploy scenario showcases (1) only and leaves (2) out of the picture. Conversely, one might construct a scenario that does not use the depot but interactively spawns subsystems by the means of updating init configurations at runtime.
To follow the topic (2), one fun experiment would be to let the user edit the configuration of a dynamic init by using Vim (running in a Noux runtime). The configuration for the dynamic init would come from a 'config' file stored in a 'ram_fs'. The RAM file system is mounted in the Noux instance. Its content is also made available in the form of ROM modules via the 'fs_rom' service. By letting the dynamic init obtain its 'config' ROM from this 'fs_rom' service, we feed it the content of the file stored in the RAM fs. For starting a new subsystem, the user would add a '<start>' node and save the file. The saving of the file results in a ROM-module update, which triggers the dynamic init instance to process the modified version.
The visibility of the Noux instance could be toggled via a global key (like the X-ray mode is handled in the demo.run script). By implementing this simple scenario, you would actually get a quite powerful "shell". ;-)
That's sounds like a challenge for me :-) ...
Ok, now I get the "picture". Thanks for your time to explain in detail about the problems and solutions.
Cheers Jörg