Checkpoint/restore of capabilities
Norman Feske
norman.feske at ...1...
Wed Aug 31 18:43:43 CEST 2016
Hello Denis,
> After a restore of a component the capability space shall be the "same"
> as before the checkpoint:
> 1) The capabilities after the restore shall point to corresponding
> object identities.
> 2) Also the capabilities after the restore shall be on the same slot
> (have the same address) in the capability space as before the checkpoint.
>
> The capability space resides in the kernel and Genode does not offer an
> API to manipulate it. Is there a way to accomplish my goal with Genode's
> API anyway?
there is no ready-to-use solution via the Genode API because the way
capabilities are handled vastly differs between the various kernels.
Manipulating the capability space of a remote component wouldn't even be
possible on some kernels. However, since you are using a specific kernel
(Fiasco.OC) that provides an asynchronous map operation, the problem can
be tackled in a kernel-specific way.
I would propose to extend the existing 'Foc_native_pd' RPC interface [1]
with RPC functions for requesting and installing capabilities from/into
the capability space of the PD.
[1]
https://github.com/genodelabs/genode/tree/master/repos/base-foc/include/foc_native_pd
The function for requesting a capability would have an iterator-like
interface that allows the client to iterate over the PD-local selector
numbers and sequentially obtain the underlying capabilities as
Genode::Native_capability objects (which can be delegated via RPC). Each
call would return a Genode::Native_capability and a selector number of
the capability to request with the next RPC call. In a first version,
you may simply iterate over all numbers up to the maximum selector
number, returning invalid capabilities for unused selectors. The
iterator-like interface would then be a performance optimization.
The function for installing a capability would take a
Genode::Native_capability and the destination selector number as
arguments. The implementation of the 'Foc_native_pd' interface resides
in core, which has access to all capabilities. The implementation would
directly issue Fiasco.OC system calls (most likely 'l4_task_map') to
install the given capability into the targeted PD.
Does this sound like a reasonable plan?
Cheers
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
More information about the users
mailing list