Hi Norman, 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.
Daniel
On Thu, Mar 17, 2016 at 10:07 AM, Norman Feske <norman.feske@...1...
wrote:
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:
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 fork.
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.
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?
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
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main