you are right, it is quite complicated, but I think I understand the
capability concept in Genode with Fiasco.OC. Let me recap it:
I created a simple figure  to illustrate my thoughts. A component has
a capability map and a kernel-intern capability space. Each managed RPC
object has a capability which points to a capability map slot that
stores a system-global identifier called badge. The capability space
slot can be computed through the capability map slot. The corresponding
capability map slot points to the object identity which is an IPC gate.
In order to restore a component on another ECU, the checkpointed
variables representing capabilities (entries in memory, e.g. stack) have
to be made valid. Therefore, I have to restore the IPC gate, the
capability space slot pointing to this IPC gate, and allocate a new
badge, because it is valid only in one system and the component is
migrated to another system. Also, I have to restore the capability map
slot to point to the new badge and restore the RPC object.
In the following I assume that the RPC objects of the target component
are created by the Checkpoint/Restore component (i.e. it intercepts the
session requests and provides own sessions at child creation). The other
case regarding local RPC objects of the target component will be
discussed later, if I hopefully have the time:
By virtualizing the session RPC objects and the normal RPC objects, I
can checkpoint the state of them. Thus, I can recreate an RPC object.
When I do that the RPC object has a new capability (local to the
Checkpoint/Restore component) and a valid badge. Implicitly a valid IPC
gate is also recreated. Thus, the target component has to know this
capability inside its protection domain. Therefore, the capability
space/map slot has to point to the IPC gate or to the new badge,
* The capability space slot is recreated by issuing l4_task_map to map a
capability from core to the target child. This is done by extending
Foc_native_pd interface (see in an earlier mail from Norman).
* The capability map slot is recreated by
Capability_map::insert(new_badge, old_kcap). Thus, I have to checkpoint
the kcap by Capability_map::find(new_badge)->kcap().
Now I am missing the pointer to target component's internal capability
map. I already have all dataspace capabilities which are attached to the
target's address space. With the pointer I can cast it to a
Capability_map* and use its methods to manipulate the Avl-tree. Please
correct me if I am wrong.
Norman, you proposed a rough idea of how to obtain a dataspace
capability of the capability map through the PD_session in one of your
On 07.10.2016 09:48, Norman Feske wrote:
>2. We may let the child pro-actively propagate information about its
> capability space to the outside so that the monitoring component can
> conveniently intercept this information. E.g. as a rough idea, we
> could add a 'Pd_session::cap_space_dataspace' RPC function where a
> component can request a dataspace capability for a memory buffer
> where it reports the layout information of its capability space.
> This could happen internally in the base library. So it would be
> transparent for the application code.
Can you or of course anyone else elaborate on how it "could happen
internally in the base library"? Does core know the locations of
capability maps of other components?
PS: If my thoughts contain a mistake, please feel free to correct me. It
would help me a lot :)
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
genode-main mailing list