cli_monitor vs launcher vs launchpad

[Jörg-Christian Böhme]

Hi Norman,

thanks for your quick answer and also for the detail information.

Last days, I tried quickly to get an overview in my less spare time :-) of 
the many information (read the discussion and "Package management on 
Genode"
documentation, study the source code etc) so please take into account when 
I misunderstood something.

Am Freitag, 18. August 2017 15:58:49 CEST schrieb Norman Feske:
>
> However, all these solutions share one problem that holds them back for
> general-purpose scenarios: They can start and stop subsystems but do not
> allow the user to define any interaction between the subsystems. It is
> not possible to dynamically launch a new service to be used by another
> subsystem.
>
Hm, ok. I was expected it was... I saw the "Genode as Desktop OS" 
presentation from you at FOSDEM 2016. You show there the Turmvilla scenario
and demonstrate via the CLI_monitor (I think it was the CLI_monitor... 
the video resolution and the tone has not the best quality) how you can 
dynamically change the configuration of for example the screen resolution. 
Ok to launch dynamically a new service you didn't show there.
>
> 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" ?
>
> It goes without saying that the
> lessons learned from the menu-view approach can be applied in this
> scenario as well. Please refer to a previous discussion [1] that we had
> on the list earlier this year.
>
> [1] https://sourceforge.net/p/genode/mailman/message/35787965/
>
I have to admit, that I partially understand this discussion but not in
detail. I think I need more experience in Genode :-)
>
>> Here some background information, why I asked...
>> I will use genode as a desktop system and for such a use case I need
>> something to launch applications. I notice, that genode is currently
>> implementing a package management and it sounds like for me, in the
>> future I need a launcher that are flexible enough to start an application
>> after I installed a package in genode :-) ... but step by step.
>
> I am currently working in the same direction. If you are interested to
> follow my work, you may have a look at the corresponding branch [2]. In
> my opinion, two particular interesting bits are the depot-query scenario
> [3] and the dynamic-drivers subsystem [4]. Both facilitate the dynamic
> init approach.
>
> [2] https://github.com/nfeske/genode/commits/nitro
> [3]
> https://github.com/nfeske/genode/commit/cc2b7935fbdbe0bd3b342495bcc9d1da36e61f55
> [4]
> https://github.com/nfeske/genode/commit/8046e4d2be50c183ad7ad3ba6e68d6e0a7240644
>
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 ?

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 -> ...]
But only the "root" init get the full ressoruces from the "core" or?

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 ?
>
> But as a word of caution, this is work in progress. ;-)
>
Ok, I see but it looks create for me. 
Also the dynamic-driver is a create solution I think.
I decided to stop my work/idea for the "launcher stuff" now and waiting/try
to use the depot-query solution :-).

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

Cheers
Jörg