Well, I've been working with projects that involve checkpointing for
about 5 years now, and am in fact rewriting a userland checkpointing
facility for Solaris right now.

A kernel checkpoint/restore facility is certainly useful, but currently
you will always need userland support and even stubs for system calls.

For example: checkpointing is done with signals. A signal can occur
when you're in a shared library. Suppose this happens. You save
your state, etc, and restart. However, the shared libraries are
possibly mapped at a different address now. So, you return from the
signal handler into the middle of nowhere. You can work around this by
linking statically, but this isn't even completely possible on Solaris
nowadays. So you need to deal with this somehow, and with other
mmap-ed files.

The mmap-state saving support is a bit tricky in the kernel, because
all that the VM system knows is a vnode, and there is currently no
reasonable way to get from vnode -> filename. So you need userspace
support. A way to do this, is to intercept mmap and have it maintain
a list of <filename,range,prot,address> tuples, so that they can
be restored. Solaris makes this a bit easier, because there is a
/proc ioctl that provides you with all the current mappings for
a process.

I almost started implementing a kernel interface in NetBSD for
checkpointing, just to see what problems I'd stumble on. My intended
interface was fckpt(pid, fd) (take image of process "pid" and
write it to "fd"), and frestart(fd). I might still do this when I get
some time, but until the vnode -> filename issue is resolved I think that
userspace implementations are the way to go. I did port the Condor
checkpointing to NetBSD once, but I'm not sure if I have the source
around still (I doubt it).

- Frank