Messages in this thread | | | Date | Sat, 22 Oct 2011 12:49:01 -0400 | Subject | Re: [patch 5/5] elf: Add support for loading ET_CKPT files | From | Dan Merillat <> |
| |
On Fri, Oct 14, 2011 at 1:10 PM, Tejun Heo <tj@kernel.org> wrote: > I don't think this is a good idea. We already have most of interface > necessary for restoring task state and there's no need to put it into > the kernel as one piece. If there's something which can't be done > from userland using existing interfaces, let's please discuss what > they are and whether they can be resolved differently first.
I may be missing something, but programs do care about their and their children's PIDs, and even with a kernel interface to pick a specific PID for a new process (yikes!) it wouldn't work if the original PID was in use by another process.
Open file handles that point to files that have been changed/deleted while the process was frozen, unlinked scratch files that are gone for good when the original process dies, shared memory, processes at the other end of pipes, etc. Graphical programs get even worse, with trying to reproduce the X11 state or GPU state. Network isn't as bad, as it's expected that it could be dropped at any time so most programs can handle it.
If the userspace to be checkpointed can cope with all that, it can handle moving the vdso mapping. Since it has to have specific logic to handle all the different types of , why not just have it dump internal state on a signal and rerun with that file as an argument? The target process that can deal with being externally frozen would seem to be basically a tech demo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |