Quoting Dave Hansen (dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):

On Mon, 2008-10-27 at 17:51 -0400, Oren Laadan wrote:

quoted

quoted

      Instead, how about a flag to sys_checkpoint() -- DO_RISKY_CHECKPOINT --
which checkpoints despite !may_checkpoint?

I also agree with Matt - so we have a quorum :)

so just to clarify: sys_checkpoint() is to fail (with what error ?) if the
deny-checkpoint test fails.

however, if the user is risky, she can specify CR_CHECKPOINT_RISKY to force
an attempt to checkpoint as is.

This sounds like an awful lot of policy to determine *inside* the
kernel.  Everybody is going to have a different definition of risky, so
this scheme will work for approximately 5 minutes until it gets
patched. :)

Is it possible to enhance our interface such that users might have some
kind of choice on these matters?

Well we could always just add a field to /proc/self/status, and let
userspace check that field (after freezing the task) for the
presence of CR_CHECKPOINT_RISKY and make up its own mind.

Though my preference is for simplicity - just refuse the checkpoint.
That way people might screan loudly enough for us to support the
features they want.  If we let them just bypass and hope for the
best that starts to dilute some of the intended effect of all this.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html