Hello Norman, your approach sounds really good and promising. But I have a problem when storing the Capabilities from the Cap Space of the child:
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). 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? 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? Kind regards, Denis On 31.08.2016 18:43, Norman Feske wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
