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
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
