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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers