<div dir="ltr"><div><div></div>The more I think about this (and experiment) the more I think that process hibernation is quite feasible in Genode (assuming reconstruction of state in dependent services) and much easier than in a traditional UNIX based systems where process state is thrown around and difficult to track/get to without kernel help. Being able to serialize processes (and identify all state belonging to a process) could be a real differentiator for Genode in the long run. Such a capability would have direct relevance to scalability and future storage class memories.<br><br></div>Daniel<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 11:41 AM, Daniel Waddington <span dir="ltr"><<a href="mailto:waddy16925@...9..." target="_blank">waddy16925@...9...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Norman,<br></div>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.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Daniel<br><br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 10:07 AM, Norman Feske <span dir="ltr"><<a href="mailto:norman.feske@...1..." target="_blank">norman.feske@...1...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<br>
great to see you back in Genode land! :-)<br>
<span><br>
> I'd like to be able to freeze a process (PD or even a vmm), make it<br>
> persistent, and unfreeze at some later point in time. Does anyone have<br>
> suggestions/pointers on how to do this?<br>
<br>
</span>This does not work out of the box but I see two principal approaches:<br>
<br>
1) You can run the to-be-frozen program as a child of a custom runtime<br>
environment that intercepts the program's PD, CPU, RM, and RAM<br>
sessions. So the environment knows everything that goes on within<br>
the program. This is what the Noux runtime is doing. Thanks to<br>
this approach, we are able to implement fork on top of Genode. This<br>
is actually very similar to what you want to achieve. Instead of<br>
replicating the forking program, however, you would serialize/<br>
unserialize this information. That said, there are some constraints<br>
worth noting. Most importantly, the new process "forgets" all its<br>
capabilities. So it must re-obtain them in order to work as<br>
expected. In Noux processes, this is possible because we hide<br>
Genode capabilities behind the POSIX API. So only the libc deals<br>
with capabilities and can actively re-establish them after the<br>
fork.<br>
<br>
Another example to look at is the GDB monitor. Similar to Noux,<br>
it intercepts the said core services. But it uses them to inspect<br>
and control the to-be-debugged program.<br>
<br>
2) Our general agenda is to create components as mere state<br>
machines that are fed with state (e.g., using ROM sessions)<br>
and propagate their results (e.g., using Report sessions). Since<br>
such components don't contain unrecoverable internal state,<br>
we can just kill and restart them. When presented with the<br>
same imported state (aka ROM sessions) after the restart, they<br>
end up in the same internal state as before. A practical<br>
example of this approach is the way, the window decorator<br>
interacts with the window manager in the Turmvilla scenario.<br>
Here, we can dynamically replace one decorator component by<br>
another implementation while retaining all of the window layout.<br>
<br>
This approach just defines the problem away, which I find very<br>
nice. :-)<br>
<br>
For complex monolithic applications with comprehensive internal state,<br>
there is the further option to run it with a VM (i.e., VirtualBox).<br>
Although we haven't tried it with our port, VirtualBox comes with the<br>
ability to suspend a VM to a file. I think this feature could be enabled<br>
in our version of VirtualBox without too much trouble.<br>
<br>
Can you share more details about your use case?<br>
<br>
Cheers<br>
Norman<br>
<br>
--<br>
Dr.-Ing. Norman Feske<br>
Genode Labs<br>
<br>
<a href="http://www.genode-labs.com" rel="noreferrer" target="_blank">http://www.genode-labs.com</a> · <a href="http://genode.org" rel="noreferrer" target="_blank">http://genode.org</a><br>
<br>
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden<br>
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth<br>
<br>
------------------------------------------------------------------------------<br>
Transform Data into Opportunity.<br>
Accelerate data analysis in your applications with<br>
Intel Data Analytics Acceleration Library.<br>
Click to learn more.<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140" rel="noreferrer" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140</a><br>
_______________________________________________<br>
genode-main mailing list<br>
<a href="mailto:genode-main@lists.sourceforge.net" target="_blank">genode-main@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/genode-main" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/genode-main</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>