Hello Norman,
Am Montag, 28. August 2017 12:05:38 CEST schrieb Norman Feske:
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).
Ok, I read "4.6.3 Dynamic component reconfiguration at runtime" in the
Genode documentation, but I forgot that the "root config" from core is
read only.
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". ;-)
That's sounds like a challenge for me :-) ...
Ok, now I get the "picture".
Thanks for your time to explain in detail about the problems and solutions.
Cheers
Jörg
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
