<div dir="ltr">Pawel,<div><br></div><div style>How did everything go this last week?</div><div style><br></div><div style>Would it make sense to look at going ahead and committing the existing work you have done to master? (Since if it can save/restore a regular threaded process, it is independently useful).</div>
<div style><br></div><div style>Sam</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 30, 2013 at 10:52 PM, Pawel Dziepak <span dir="ltr"><<a href="mailto:pdziepak@quarnos.org" target="_blank">pdziepak@quarnos.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Recently, I have completed support for checkpointing processes with<br>
multiple threads by saving and restoring signal information. That<br>
included keeping information on thread's signal mask and alternate<br>
stack for signal handlers (apparently, signal stack info wasn't saved<br>
even for the main thread). That required changing of the ckpt_siginfo<br>
structure. However, since it is used only by coredump save and<br>
checkpoint restore code there won't be any serious compatibility<br>
consequences.<br>
<br>
I've also spent some time on testing to ensure that everything works<br>
well regardless of the hardware architecture (x86, amd64, and<br>
vkernels). Since I haven't found any problems I am now going to (a<br>
week earlier than planned) to start working on reopening network<br>
interface used by vkernel and restoring its configuration.<br>
<br>
Paweł<br>
<br>
</blockquote></div><br></div>