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/cc2b7935fbdbe0bd3b342495bcc9d1da36e6... [4] https://github.com/nfeske/genode/commit/8046e4d2be50c183ad7ad3ba6e68d6e0a724...
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