Intercepting ram session of child

[Denis Huber]

Hello Norman,

thank you for your well-written answer :)

On 17.08.2016 14:06, Norman Feske wrote:
> 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.

This means, the Rpc_objects can communicate, if they are managed by the 
same Entrypoint, but not if they are in different Entrypoints. Just out 
of curiosity: Can I delegate a capability from one Entrypoint to another?

> 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?

Thanks, this explanation helped me to solve the initial problem and I 
could also implement the PD and CPU Rpc_objects (without root objects), 
which intercept the child's session methods.

Now my problem is the following: If I apply your solution and start a 
child with a custom RAM Rpc_object, then the program hangs up on the 
child creation. I have created a simple program [1] (child component 
[2], run script [3]) to demonstrate the error. The output is

[init -> random] All is fine until now!
Error: Test execution timed out
Makefile:261: recipe for target 'run/random' failed
make: *** [run/random] Error 254

This demonstrates that all resource-object creations before the child 
object creation passed without errors. But the program hangs up on the 
creation of the child. What could be the error?


Best regards
Denis

[1] 
https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b3c5732e01f2dc02fb81082f5c38bd23f86b/src/random/main.cc

[2] 
https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b3c5732e01f2dc02fb81082f5c38bd23f86b/src/sheep_counter/main.cc

[3] 
https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b3c5732e01f2dc02fb81082f5c38bd23f86b/run/random.run