Hi Jörg,

first, your understanding of the different components is correct. Thank
for taking the time for the thorough investigation of the existing
components.

> What I see between the cli_monitor/launcher and launchpad approach, that
> the configuration of the subsystems is different. But is there even more
> differences ?

The launchpad and qt_launchpad were intended as quick demos, not a
serious solutions. In fact, launchpad was one of the very first programs
developed for Genode - just to showcase the dynamic creation/destruction
of subsystems. CLI monitor is similar, but uses a textual interface.

Design-wise the disadvantage of the launchpad as well as CLI monitor
(and even more so qt_launchpad) is the fact that the component is
potentially complex (as it implements a UI) while being part of the TCB
of each launched subsystems.

With the launcher, I explored the idea to separate the complex parts
(i.e., the widget rendering) into a separate sandboxed component called
menu view. This helps to significantly reduce the complexity of the
launcher - and thereby the TCB of the launched subsystems. So
software-design wise, the launcher is much more advanced.

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.

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

> May I asked, what are the future plans of these "launchers"?
> Cli_monitor is in the OS repo and sounds like the API is what I should use
> to implement some "own" launchers.
> Launch app in gems repo, as what I understand from the email from Norman
> (see Friday, 4. August 2017 11:56:38 CEST from Norman Feske) this is
> outdated.
> Launchpad is in the demo repo and what I see in the git commit history,
> this is also the older approach to "launch" subsystems in genode, or?

The launchpad is meant to stay as a quick-start example for exploring
Genode. However, the other launchers will eventually be replaced by the
dynamic init approach, once it is there.

> 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

But as a word of caution, this is work in progress. ;-)

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@...172...net
https://lists.sourceforge.net/lists/listinfo/genode-main