[PATCH 00/80] Kernel based checkpoint/restart [v18]

[Serge E. Hallyn]

Quoting Daniel Lezcano (daniel.lezcano at free.fr):
> Serge E. Hallyn wrote:
>> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>>   
>>> Dan Smith wrote:
>>>     
>>>> The header file makes it pretty clear what is going on,       
>>> Certainly for you.
>>>     
>>
>> If you're worried about hooking lxc-restart up and that
>> being a mess, 
> Yep, I am worried about that too :)
>
>> i have said that as soon as something hits -mm,
>> I will hook up lxc-restart.  I do agree, the userspace code
>> would be much simpler if we didn't need to do all of the
>> process tree creation in userspace :)
> Yes and I know there were discussions about this point several times for  
> the proctree, I won't argue with kernel vs user proctree creation.
> But what I understood is you will continue to parse the statefile to  
> recreate some other resources like a subset of the network and here I am  
> lost.

If network devices end up being recreated in userspace - either the
ones for the root restarted container, or all the devices including
for any child network namespaces - then I believe they will be
considered container objects.  All the container information is at the
top of the checkpoint file, so the program coordinating the restart
will see all of the information before the task hierarchy.  Actually, I
thought linux-2.6/Documentation/checkpoint/readme.txt used to
explicitly show a 'container information' section between the
image header and task hierarchy.  Oren?

> Who in the linux community will understand what is checkpointed and what  
> is restored from the kernel or from the userspace ?

It should all be documented linux-2.6/Documentation/checkpoint/.  But
right now it's not even settled whether process creation in userspace
is going to be the final acceptable way, so documenting speculation
about how we're going to do network devices just seems too certain to
not end up matching reality.

> Does this imply someone has to use a specific tool like "restart.c"  
> within its own tools, assuming this tool is installed in the system or  
> shall he copy-paste the code of the GPL licensed restart.c to its LGPL  
> licensed tools ?

Hmm, I think a tiny little lgpl library, maybe even shipping under the
kernel tree, implementing a generic, whole-container and sub-tree
checkpoint and restart, makes very good sense.

It certainly does NOT make sense to require multiple projects to track
all changes to the checkpoint image format as the kernel changes...

-serge