[Devel] Re: [PATCH 0/6] /proc/pid/checkpointable

[Dave Hansen]

On Wed, 2009-03-18 at 13:48 -0400, Oren Laadan wrote:
> Dave Hansen wrote:
> > On Wed, 2009-03-18 at 12:16 -0400, Oren Laadan wrote:
> >> My suggestions works for this two: we add a flag CR_CTX_DRYRUN; a task
> >> can ask to checkpoint itself, or another task, with CR_CTX_DRYRUN and
> >> the checkpoint code runs without actual effect. (If we don't want to
> >> expose the actual flag to userspace, then we simply use it in an
> >> implementation of a /proc/PID/checkpointable operation).
> > 
> > This mostly falls short answering the question "Where/when did I go
> > wrong?"  Personally, I think that is critical for getting good bug
> > reports out of normal Joes that might not really be interested in c/r
> > development itself.  It is like lockdep.  The guys/gals posting those
> > reports really don't know about kernel locking, but they are able to
> > improve it anyway.
> > 
> 
> As long as we have the descriptive text accompanied, it will answer the
> "where/why" question.
> 
> I can't think of an example where for me, as the developer, the "when"
> question was important in finding and fixing an unsupported corner.
> 
> Can you think of examples where this would be that much more informative
> then simply answering the "where/what" question ?

I think it is crucially important if a ->may_checkpoint-style flag is
persistent and sticky.

If we're *just* considering moment-by-moment state it doesn't matter at
all.

How about I rephrase: "Where/when did I first go wrong?"

I consider that an important question to answer.  What was the first
thing that I did that made this thing uncheckpointable?  If I want my
container to always be checkpointable, how else do I find race
conditions that may may it uncheckpointable for a moment?

Yep, it requires extra code.  But it also completely changes the way in
which we can go after features.  Oh, well.  You don't like it.  It is
different from how Zap did it.  Let's drop it.

-- Dave

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers