Hello Stefan,

On 04.07.19 14:27, Stefan Thöni wrote:

We observed that when using a file system session for the vfs of a component with serveral parent init components with long names, the session connection failed. We believe this is caused by a label that got too long, because after we shortened the names of some components the session connection started working. The problem seemd to arise when the composite label exceedeed about 110 characters.

Is there a specific limit on the length of labels? Is there a recommended workaround for that problem in a dynamic deploy environment?

indeed, the session label is transferred as RPC argument [1], which is thereby constrained by the maximum size of the IPC buffer. We considered transferring the session arguments (including the label) differently - via a shared memory buffer - but we haven't realized this plan so far. The issue is related to [2]. It is not being worked on though.

[1] https://github.com/genodelabs/genode/blob/master/repos/base/include/parent/p... [2] https://github.com/genodelabs/genode/issues/2689

As a work-around, I found the rewriting of session labels in the <route> definitions handy. For example:

<route> <service name="ROM" label_last="platform_info"> <parent label="platform_info"/> </service>

<service name="Block" label_prefix="Linux VM ->"> <child name="part_blk" label="partition 3"/> </service> ... </route>

So a long label as supplied by a client is rewritten to a short one. This can in principle be done at different levels of the component tree. Granted, this approach discards parts of the labeling information. But in practice I found that only the first or the last part of the label are actually taken into account for routing or policy decisions. E.g., the actual identity of a client (long label) is not important for a server, only the role of the client (expressed as a short label).

Following this practice, we did not encounter the limited label size as a practical problem in Sculpt so far. Should the limitation become a burden for you, however, please tell us. So we will have to bring forward our rough idea of transferring session arguments using shared memory. But since this work is quite elaborate (affecting the parent interface), I'm not eager. ;-)

Cheers Norman