Re: [BIG RFC] Filesystem-based checkpoint

[Dave Hansen <dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

On Thu, 2008-10-30 at 15:47 -0400, Oren Laadan wrote:
>   3. Your approach doesn't play well with what I call "checkpoint that
>   involves self". This term refers to a process that checkpoints itself
>   (and only itself), or to a process that attempts to checkpoint its own
>   container.  In both cases, there is no other entity that will read the
>   data from the file system while the caller is blocked.
> 
> This is a key point for me, with multiple use cases. The simplest, if
> you will, is for a process to simply checkpoint itself (no containers
> and other crap :p). Same for dumping your own container. And there are
> others.

Let's take a step back here.  I believe that strictly enforcing this
requirement strictly requires that the checkpoint be done in its
entirety by the kernel.

A process must have its state serialized in a repeatable way.  That
basically precludes  it running during the checkpoint, or having its
state change in any way that isn't atomic.

If a process can't be, itself, running during a checkpoint, then
something running must be performing the checkpoint.  That "something"
must either be another process or the kernel.  Since you've defined the
goal as a self-checkpoint, it *can't* be another process.  So, it *must*
be the kernel.

When it comes down to it, I think this point drives quite a bit of the
implementation.  The cr_kread/write(), for instance.  We *need* the
kernel to do the writing since we've completely precluded userspace from
doing it.

-- Dave