Hi Emery,

I am very happy to see the dynamic init being picked up for experimentation.

From my perspective, we do not need to agree on one single way of how

init's configurations are generated. Even though I used the term "subsystem manager" in my previous postings, it was not my intention to suggest that there is one single subsystem manager for Genode. In contrary, different scenarios call for different implementations that take scenario-specific heuristics and policies into account. E.g., in a scenario where devices are probed and drivers are loaded dynamically, the subsystem manager needs to interpret information coming from usb_drv and platform_drv. But in other scenarios, this complexity is unwanted. For rather static scenarios, it might be preferable to use a ROM filter to generate the init configuration. In yet another scenario, the user might wish to edit the init configuration by hand (or by shell scripts) and use git to version them.

In short, I think there are too many approaches to introduce a useful formalism we all may agree on. I see the dynamic init as the only common ground for now.

That said, we should strive to agree on a common way to express what a subsystem represents - so that different subsystem-manager implementations can interoperate with the same subsystems.

Let me outline my current idea that is very much intertwined by my work on the package management. Admittedly, it may be a bit intangible without studying [1]:

[1] https://github.com/genodelabs/genode/issues/2339

* A subsystem comes in the form of a pkg archive. (not each pkg archive is a subystem, but each subsystem is represented as a pkg archive)

* A subsystem pkg archive refers to a number of raw, bin, and other pkg archives that form the ROM environment of the subsystem.

* Additionally, the pkg archive contains a *.runtime file that describes the expectations of the subsystem from its environment.

When starting a new subsystem, the subsystem manager will receive the subsystem pkg archive as an argument (e.g., as a path to its local VFS). It interprets the contained 'archives' file by looking up all the ingredients from the depot. For each file found in the used archives, it generates a ROM route like this:

<service name="ROM" label="decorator"> <service name="depot"

label="/genodelabs/bin/x86_64/decorator-2017-04-26/decorator" /> </service>

The "depot" ROM server may be a 'fs_rom'. This way, all ROM-session requests originating from the to-be-started subsystem will be routed to a version-specific location within the depot.

Next, the subsystem manager inspects the '.runtime' file found in the pkg archive, which may look like this (just a rough sketch):

<runtime> <start binary="init" config="noux_bash.config" ram="32M" caps="500"/> <rom name="init"/> <rom name="noux"/> <rom name="noux_bash.config"/> <rom name="bash.tar"/> <rom name="ld.lib.so"/> <rom name="terminal"/> <framebuffer resizeable="yes"> <minimum width="500" height="400"/> <preferred width="1024" height="768"/> </framebuffer> <input/> <timer/> <file_system label="depot"/> <file_system label="user"/> </runtime>

The runtime declaration tells the subsystem manager the prerequisites of the subsystem and can be seen as a contract between the subsystem and the subsystem manager.

The '<start>' node tells the subsystem manager the information to put into the corresponding '<start>' node of the dynamic init. The other nodes are a white list of session requests that the subsystem is expected to initiate. All requests not listed in the runtime definition should be denied.

The example above is just a sketch and not set in stone. XML makes it fairly intuitive and easy to expand. So to start off, I propose to build a few subsystems and also a few subsystem managers in this way and see how well it works.

Once we observe common patterns shared by our respective subsystem-manager implementations, we can introduce formalisms or extract common utility functions.

Cheers Norman

On 05.05.2017 02:14, Emery Hemingway wrote:

Hello list,

To continue last month's interactive GUI thread, I have a proposal for the interplay between GUIs and the subsystem manager.

I too would like a new way of launching and managing subsystems, but I prefer not dedicate any on-screen area for persistent menus. I would also live without any buttons if I could. I did some prototyping and found that I gravitate towards short-lived terminal components for user interaction as opposed to long-lived components such as cli_monitor or launcher. Rather than rework what I had into something that can appear and disappear in its lifetime, I figured that XML editing via Report sessions can support ephemeral menus and would require no modification of existing components.

I have a simple proof of concept that opens a file for writing and responds to Report requests to add or remove XML nodes from the file's top-level element. This combined with fs_rom is enought to dynamically add and remove subsystems from init. Its too rough to publish now but it never need be a complictated implementation.

I mentioned this to Christian Helmuth off-list and he suggested that it would be a transactional editor, which makes perfect sense. The tree can contain inline edit annotations or the XML could be stored as different revision files with a symlink pointer to the current version. This would allow for configuration replay without a lot of overhead or specialized tooling.

Does this seem like a reasonable style of init mangagment that we can all get along with, I missing something?

cheers, Emery