Process migration and persistence
waddy16925 at ...9...
Thu Mar 17 19:41:10 CET 2016
Thanks for the extensive reply (I expected no less from you ;-)). I need to
think on your input. I don't have a concrete use-case yet, I'm simply
thinking about fast time-multiplexing of huge numbers (e.g., millions) of
application instances that can't all be held in memory at once and can't be
combined. I'm thinking about how Genode/microkernels relates to unikernels
and mirage OS/jitsu objectives.
On Thu, Mar 17, 2016 at 10:07 AM, Norman Feske <norman.feske at ...1...
> Hi Daniel,
> great to see you back in Genode land! :-)
> > I'd like to be able to freeze a process (PD or even a vmm), make it
> > persistent, and unfreeze at some later point in time. Does anyone have
> > suggestions/pointers on how to do this?
> This does not work out of the box but I see two principal approaches:
> 1) You can run the to-be-frozen program as a child of a custom runtime
> environment that intercepts the program's PD, CPU, RM, and RAM
> sessions. So the environment knows everything that goes on within
> the program. This is what the Noux runtime is doing. Thanks to
> this approach, we are able to implement fork on top of Genode. This
> is actually very similar to what you want to achieve. Instead of
> replicating the forking program, however, you would serialize/
> unserialize this information. That said, there are some constraints
> worth noting. Most importantly, the new process "forgets" all its
> capabilities. So it must re-obtain them in order to work as
> expected. In Noux processes, this is possible because we hide
> Genode capabilities behind the POSIX API. So only the libc deals
> with capabilities and can actively re-establish them after the
> Another example to look at is the GDB monitor. Similar to Noux,
> it intercepts the said core services. But it uses them to inspect
> and control the to-be-debugged program.
> 2) Our general agenda is to create components as mere state
> machines that are fed with state (e.g., using ROM sessions)
> and propagate their results (e.g., using Report sessions). Since
> such components don't contain unrecoverable internal state,
> we can just kill and restart them. When presented with the
> same imported state (aka ROM sessions) after the restart, they
> end up in the same internal state as before. A practical
> example of this approach is the way, the window decorator
> interacts with the window manager in the Turmvilla scenario.
> Here, we can dynamically replace one decorator component by
> another implementation while retaining all of the window layout.
> This approach just defines the problem away, which I find very
> nice. :-)
> For complex monolithic applications with comprehensive internal state,
> there is the further option to run it with a VM (i.e., VirtualBox).
> Although we haven't tried it with our port, VirtualBox comes with the
> ability to suspend a VM to a file. I think this feature could be enabled
> in our version of VirtualBox without too much trouble.
> Can you share more details about your use case?
> 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
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> genode-main mailing list
> genode-main at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users