Dave Hansen wrote: > 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. Stepping in a little late into the conversation here, but a self-checkpoint to me means "initiated by self". It doesn't preclude a userland service (outside our container or whatever) performing the grunge work for us once asked. > > 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 > > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers