XML editing for dynamic subsystems

[Norman Feske]

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



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