[RFC][PATCH 00/11] track files for checkpointability
dave at linux.vnet.ibm.com
Fri Mar 6 11:42:04 PST 2009
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
> 1. a short-term way to prioritize resources to support
> 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
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.
More information about the Containers