cli_monitor vs launcher vs launchpad

[Norman Feske]

Hello Jörg,

>> 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).
> I investigate in the source that depot_query component is query the
> package depot directory. When they found a package with "runtime" file
> they announced this via "blueprint" label to depot_deploy component.
> They generates the config for the "dynamic init" instance (here subinit)
> and the
> subinit is starting the "test-fs_report-2017-08-23" process (or
> subsystem?!) with the generates config from depot_deploy component.
> Is my investigation/conclusion correct ?

Yes.

> This means the "subinit" in the depot-query scenario should be the
> "dynamic init" instance what we are talking about, or is this
> "test-fs_report-2017-08-23" the  "dynamic init" instance ?
> 
> This means we have three running init instances, yes ?
> [init -> subinit -> test-fs_report-2017-08-23 -> ...]

You understood everything correctly.

> But only the "root" init get the full ressoruces from the "core" or?

Yes. In the run depot_deploy.run script, most memory remains unused. But
by assigning an overly large quantum of RAM to 'subinit', init will
transfer the maximum amount possible to 'subinit'. From this point on,
all the memory is at the disposal of the dynamic system.

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

With this scenario in place, I think the use of the depot will appear as
just another step.

> Maybe I found a little "resource/performance" issue.... I noticed that
> depot_deploy announce an "init.config" three times, but I think only the
> last
> one with the "pkg" config is important. The first and second init.config
> only announce the "static" content configuration. Maybe we should
> prevent this and verify via an if statement if the "blueprint xml" has a
> "pkg" xml node. I test it and for me it looks like it works.... but this
> is only a hint :-), maybe I didn't see some "side effects".

In principle, I agree. However, for now, I deliberately leave such
artifacts there to put stress on components that consume intermediate
states. It is important that such components can gracefully deal with
many (and sometimes arguably silly) state changes without stumbling.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth