Storage device considerations

[Norman Feske]

Hi Markus,

I will leave the first two questions to Sebastian. Let me just cover the
third topic.

> (3) Using the part_blk service, it is possible to redirect children to
> different partitions of the same storage device. What I'm interested
> in is somehow the inverse. Is it even possible for a child to get
> access to multiple block devices? I think it is quite a limiting
> constraint if a child can only access one single storage device.

This is actually possible by using the session label. If a client opens
a new block session via the 'Block::Connection' class, the constructor
accepts an optional 'label' argument. This is a string that will be
appended to the session label of the process. For example, if Vancouver
would open a block session without specifying the argument, the session
label would be just the name of the Vancouver instance, i.e.,
"vancouver". This label is supplied to the block service, which can then
base its policy on this information. For example, the 'part_blk' service
evaluates the label to assign partitions to its clients. By supplying an
additional 'label' argument to the 'Connection' constructor, multiple
sessions with different labels can be created. Those sessions can be
differentiated by the 'part_blk' service. If specifying the label
"disk0", 'part_blk' will see the label "vancouver -> disk0".

This mechanism works for assigning different partitions of the same
'part_blk' service to different block sessions of a single program.
However, you might also want to route different block sessions to
different services. For example, to connect Vancouver's "disk0" to
partition 3 of a 'part_blk' instance, and connect Vancouver's "disk1"
directly to an USB storage driver. This is possible by referring to
label session argument in the routing policy in the configuration. For
an example, take a look at 'ports/run/noux_terminal_fs.run' and look for
the '<if-arg>' node. Here, one instance of Noux should be connected to
two different instances of terminal implementations. One terminal
session is used for the stdio the init process and another session is
used to expose a virtual character device to the Noux environment. The
routing policy looks as follows:

  <route>
    <service name="Terminal">
      <if-arg key="label" value="noux"/>
      <child name="terminal_noux"/>
    </service>
    <service name="Terminal">
      <if-arg key="label" value="noux -> noux(terminal_fs)"/>
      <child name="terminal_test"/>
    </service>
    <any-service><parent/><any-child/></any-service>
  </route>

The first route is taken only if the 'label' of the session matches
"noux". In this case, the session is routed to the 'terminal_noux'
service. Otherwise, if the label matches "noux -> noux(terminal_fs)"
(where "noux(terminal_fs)" is the part of the session label explicitly
passed to the constructor of 'Terminal::Connection'), the session is
routed to the 'terminal_test' service instead.

I hope this information is of help for building more complex scenarios.
Admittedly, the '<if-arg>' session-routing mechanism is not documented
right now because we were not quite sure whether to keep it or not.
However, it turned out to be helpful in many situations. So we will most
likely stick to it. So we should definitely add this feature to the
documentation of the init process.

Thanks for bringing up this topic.

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