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 ? greg didn't say there was _no_ kernel support. without discussing the pros and cons of such and such implemention, full C/R from kernel means more maintenance work from kernel maintainers, so it seems a good idea to leverage existing API when they exist. less work. duplicating the get/set of the cpu state which is already done in the signal handling is one example of extra work. now, there's a definitely a need for kernel support for some resources. the question now is finding the right path, this is still work in progress IMHO. C. -- 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
