On 15-05-18 08:08, Norman Feske wrote:
I am not able to dive deep into it, but suspect that the session-creation error is caused by the label-rewriting route. Your start node relabels the block session as "default" whereas the service-forwarding policy of the `drivers -> dynamic` subsystem uses " default" (note the leading whitespace) [1] as policy selector, presuming that sessions are prefixed with the " -> " delimiter. This is the case when creating sessions from Sculpt's runtime subsystem in the unmodified scenario, but not anymore in your modified scenario.
Could you try relabeling your block session to "part_blk -> default" instead?
I changed the config to the following:
<start name="part_blk" caps="100"> <resource name="RAM" quantum="50M"/> <provides><service name="Block"/></provides> <config use_gpt="no"> <policy label_prefix="vfs" writeable="yes" partition="1"/> <policy label_prefix="blk_crypt" writeable="yes" partition="6"/> </config> <route> <service name="Block"> <child name="drivers" label="part_blk -> default"/> </service> <any-service> <parent/> </any-service> </route> </start>
However, it still gives the exact same errors. Strangely, init still gives the warning: [init] Warning: part_blk: could not revert session RAM quota (service=Block cid=6 args='tx_buf_size=4194304, cap_quota=5, label="part_blk -> ", ram_quota=4207830, diag=0' state=SERVICE_DENIED ram_quota=4207830, cap_quota=5)
It looks like the label is not rewritten at all. changing "<service name="Block">" into "<service name="Block" label=""> does not do anything and the label inside the warning stays "part_blk -> ". Does this give you any clue?
Also, placing part_blk on another init which is not the runtime init also gives me these errors, even though the label is changed to "init -> part_blk -> ".