Checkpoint/restore of capabilities

[Norman Feske]

Hi Denis,

> The child component shall be migrated from one ECU to another. The 
> Genode system on the other ECU may have the Rpc_objects, which the child 
> needs (e.g. shared dataspaces), but their object identities are 
> different (e.g. other addresses in memory) or the Rpc_objects do not 
> exist (e.g. a session object between the child and a service).

so the problem goes much deeper than merely requesting and populating
the child's capability space. You need the replicate the entire child's
execution environment at the destination ECU. That means for each
capability in possession of the child, your runtime needs to know the
exact meaning. E.g., if the child has a session capability to a session
created with certain session arguments, the same kind of session must be
re-created at the destination ECU. Of course, the same holds for all
dataspaces, threads, and other RPC objects that the child can reference
via the capabilities present in its capability space.

The logical consequence is that the runtime must virtualize all services
used by the child. E.g. if the child creates a LOG session, the runtime
would create a session to a LOG service in the child's name but hand out
a capability locally implemented LOG-session wrapper - similar to what
you have already done for the RAM service. So when migrating the child,
you now exactly what the various capabilities in the child's capability
space mean and can transfer the underlying state to the destination ECU.

In principle, this is how Noux solves the fork problem. But in the case
of Noux, I deliberately avoid populating the child's capability space
with Genode capabilities in order to alleviate the need to virtualize
many Genode services. Instead, I let the child use the Noux session as
its only interface to the outside world. At the Noux-session level, the
child does not talk about Genode capabilities but about file
descriptors, for which Noux knows the meaning. Of course there exist a
few capabilities in the child's capability space, in particular the
parent cap, the Noux-session cap, and the caps of the child's
environment. But these few capabilities are manually re-initialized by
the freshly created process after the fork.

In your case, you want to replicate the child's capability space in a
way that is transparent to the child. Like Noux, you need the have a
complete model of the child's execution environment in your runtime.
Unlike Noux, however, you want to let the child interact with various
Genode services. Consequently, your model needs to capture the those
services.

> During a restore, I will have to relink the Native_capability to the 
> available Rpc_object or simply recreate the Rpc_object. In both cases I 
> have to know the types of the Native_capabilities, when I snapshot them 
> from the Cap Space of the child. Is there a way to find out the type of 
> a Native_capability through an API function?

As discussed above, the type alone does not suffice. Your runtime needs
to know the actual semantics behind each capability, e.g., not just the
knowledge that a certain capability is a RAM-session capability but also
the information how much quota the RAM session has and which dataspaces
belong to it. Or as another example, you don't just need to know that a
capability is a file-system session but also the session arguments that
were used when the session was created.

> If there is no ready-to-use function/approach, can I intercept the type 
> to which a Native_capability is reinterpreted in Rpc_entrypoint::manage 
> as a workaround solution?

Since your runtime needs to create a representative for each RPC object
the child interacts with in the form of a locally implemented RPC object
(managed by the runtime's entrypoint), you can in principle use the
'Rpc_entrypoint::apply' method to look up the local RPC object for a
given capability.

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