Thanks, that solves it for now.
Boris
On 31-01-17 16:30, Norman Feske wrote:
Hello Boris,
When testing it with print() by inserting the following line
log("testing... session = ", session, " cap = ", cap, " equal = ", session == cap);
it outputs the following:
session = cap<socket=27,key=474> cap = cap<socket=27,key=474> equal = 0
So the comparison will always fail, and the overloaded close() and upgrade() methods of Root cannot close/upgrade the correct session.
Am I missing something here or is it not possible right now to locally keep track of multiple forwarded session capabilities in this way?
the kernel mechanisms for re-identifying capabilities vary a lot between the various kernels. For example, for seL4 I brought up this problem long ago [1] but there is still no good solution. On NOVA, the situation looks a bit brighter since we extended the kernel in this respect. In base-hw, it works.
[1] http://sel4.systems/pipermail/devel/2014-November/000114.html
For your current scenario, I recommend you to change the comparison to
session.local_name() == cap.local_name()
The 'local_name' corresponds to the 'key' you observe in the output of the capability. It is expected to be unique for the corresponding RPC object.
In the longer term, we try to largely eliminate the need to re-identify capabilities. In particular since Genode 16.11 [2], the interplay between parent and child components no longer relies on the re-identification of capabilities. It employs IDs instead. In fact, under the hood, there are no 'Root' RPC calls between components any more. But at the API level, we have not made the new facilities available yet. For now, I recommend you to use the 'local_name', or the 'Object_pool', which is a data structure that associates capabilities with a component-local object.
[2] http://genode.org/documentation/release-notes/16.11#Asynchronous_parent-chil...
Cheers Norman