Intercepting ram session of child

[Norman Feske]

Hi Denis,

first, thank you for providing a test case in such a nicely condensed
form. It is great for pin-pointing the problem.

On 14.08.2016 18:03, Denis Huber wrote:
> I tried to adopt this concept for a custom Ram session. I created a very 
> short test program [1] (Run script in [2]) which creates a custom 
> Ram_session_component and tries to transfer quota from its environment 
> to the custom Ram session component. The quota transfer fails with error 
> code -1, which means the recipient of the transfer is not a valid 
> session component [3].
> 
> I think the problem is, that I have not created a valid capability of 
> the custom Ram_session_component. What important fact do I miss in my 
> implementation? I am grateful for every hint you give me :)

Core's RAM service does not know the meaning behind the 'ram_special'
capability because this capability does refer to an RPC object living
inside your component, not inside core. Core can transfer quota only
between RAM sessions known to core. It tries to look up a RAM session
for the supplied capability argument but cannot find one. In contrast,
if you change the transfer-quota line to

  log("t: ", env.ram().transfer_quota(ram_impl._parent_ram, 4096));

the operation succeeds because 'ram_impl._parent_ram' refers to a RAM
session provided by core.

If you want the child subsystem to deal with multiple RAM sessions (such
as 'env.ram()' and a manually created RAM connection), the "non-root"
approach can no longer be applied. In order to allow the RAM sessions
refer to each other, they need to be provided by the same RAM service.
I.e., when creating the child, you will have to equip it with a RAM
session of your RAM service as done, for example, by noux. The
'_resources.ram' of the child [1] is a locally-provided RAM-session object.

Btw, you will encounter a very similar problem with the PD-session
argument for the 'Cpu_session::create_thread' operation. When forwarding
this RPC call to core, you will need to replace the capability argument
supplied by the client (which refers to your virtualized PD session) by
the "real" PD capability as known by core.

Could this explanation answer your question?

[1]
https://github.com/genodelabs/genode/blob/master/repos/ports/src/noux/child.h#L164

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