On Fri, Feb 27, 2009 at 10:19:09AM +0100, Greg Kurz wrote: > On Fri, 2009-02-27 at 01:17 +0300, Alexey Dobriyan wrote: > > On Thu, Feb 26, 2009 at 07:30:16PM +0100, Greg Kurz wrote: > > > On Thu, 2009-02-26 at 18:33 +0100, Ingo Molnar wrote: > > > > I think the main question is: will we ever find ourselves in the > > > > future saying that "C/R sucks, nobody but a small minority uses > > > > it, wish we had never merged it"? I think the likelyhood of that > > > > is very low. I think the current OpenVZ stuff already looks very > > > > > > We've been maintaining for some years now a C/R middleware with only a > > > few hooks in the kernel. Our strategy is to leverage existing kernel > > > paths as they do most of the work right. > > > > > > Most of the checkpoint is performed from userspace, using regular > > > syscalls in a signal handler or /proc parsing. Restart is a bit trickier > > > and needs some kernel support to bypass syscall checks and enforce a > > > specific id for a resource. At the end, we support C/R and live > > > migration of networking apps (websphere application server for example). > > > > > > >From our experience, we can tell: > > > > > > Pros: mostly not-so-tricky userland code, independent from kernel > > > internals > > > Cons: sub-optimal for some resources > > > > How do you restore struct task_struct::did_exec ? > > With sys_execve(). How do you restore set of uts_namespace's? Kernel never exposes to userspace which are the same, which are independent. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
