Checkpoint/restore of four specific capabilities

Joos, Lukas l.joos at
Sun Jun 17 23:19:28 CEST 2018

Dear Genode community,

I am currently trying to extend a checkpoint/restore mechanism based on Fiasco.OC and Genode 16.08 that has been discussed on this mailinglist before. [1] [2]

During my analysis of the existing code I was able to identify four capabilities that do not show up in the child's capability space after a restore:
CAP1: Fiasco.OC GATE representing Genode::Rpc_entrypoint::_exit_cap
CAP2: Fiasco.OC GATE representing Genode::Entrypoint::_signal_proxy_cap
CAP3: Fiasco.OC IRQ representing Genode::Signal_source_rpc_object::_blocking_semaphore (Fiasco.OC specific)
CAP4: Fiasco.OC GATE representing "Capability<Constructor> constructor_cap" local to the Genode::Entrypoint::Entrypoint(Env &env) constructor scope

Based on my current understanding I'd say that CAP4 is not needed after a component has been constructed.
CAP1 may be needed when a component is destroyed and CAP2 and CAP3 are needed for the signalling subsystem to work correctly.

Regarding the Fiasco.OC specific CAP3 there is also the problem that it has to be attached to the "signal handler" thread with a system call (l4_irq_attach).
The current idea (which has also been discussed previously [3])  is to delegate the thread and IRQ capabilities to core, which then invokes the syscall with the translated kcap values.

My questions are:
1) Which of those four capabilities actually need to be present in a restored child?
2) Do they have to be in the capability map?
3) Do they have to be in the capability space?
4) Does the memory where the Genode::Capability<RPC_INTERFACE> is stored inside the child component have to be altered after the restore?

If you have any ideas on how to restore one or more of those capabilities I'd love to hear all about it.

Thank you for your time.

Lukas Joos

[1] or
[2] or

More information about the users mailing list