cli_monitor vs launcher vs launchpad

[Jörg-Christian Böhme]

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