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