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