Re: [RFC][PATCH 00/11] track files for checkpointability

[Dave Hansen <dave@linux.vnet.ibm.com>]

On Fri, 2009-03-06 at 12:24 -0600, Serge E. Hallyn wrote:
> > But, these "early stage" messages are completely opposed to an approach
> > that uses sys_checkpoint() in some form (like with a -1 fd as an
> > argument).
> 
> Well I disagree with that.  The 'early stage' messages could be seen as
> either:
> 
>         1. a short-term way to prioritize resources to support
>         or
>         2. a long-term way to catch new resources introduced
>         without checkpoint/restart support
> 
> I don't believe 2. would work.  I think 1. would work, but that we
> risk imposing permanent code changes to support a temporary goal.

I should be a bit more clear.  My goal (and I think Ingo's) here is to
come up with a mechanism that will make the checkpoint feature less
likely to break once we merge it into the tree.  I'm looking for a tool
that people can utilize, even if they don't necessarily care about
checkpoint/restart.

If we *completely* depend on sys_checkpoint() as the interface for
determining if we are checkpointable, we don't have such a tool.  We
have a tool that the checkpoint/restart developers and probably some
testers can and certainly will use.  This is still very, very useful.
But, it probably won't ever generate a bug report from anyone who
doesn't specifically care about c/r.

As far as detecting *new* resources.  Well, crap.  I don't think our
little ->may_checkpoint flags can do that.  My little f_op trick will
help and is better than nothing.  But, as you noted, it is far from
perfect because we'll probably have people just copying the generic*
functions into new code.

-- Dave