text: >>> --- /dev/null>>> +++ b/checkpoint/sys.c>>> @@ -0,0 +1,35 @@>>> +/*>>> + * Generic container checkpoint-restart>>> + *>>> + * Copyright (C) 2008 Oren Laadan>>> + *>>> + * This file is subject to the terms and conditions of the GNU General>>> Public + * License. See the file COPYING in the main directory of the>>> Linux + * distribution for more details.>>> + */>>> +>>> +#include <linux/sched.h>>>> +#include <linux/kernel.h>>>> +>>> +/**>>> + * sys_checkpoint - checkpoint a container>>> + * @pid: pid of the container init(1) process>>> + * @fd: file to which dump the checkpoint image>>> + * @flags: checkpoint operation flags>>> + */>>> +asmlinkage long sys_checkpoint(pid_t pid, int fd, unsigned long flags)>>> +{>>> + pr_debug("sys_checkpoint not implemented yet\n");>>> + return -ENOSYS;>>> +}>>> +/**>>> + * sys_restart - restart a container>>> + * @crid: checkpoint image identifier>> So can we compare your api to Andrey's?Jumping in the API thread : how will this API interact with the namespaces ? I think the exact question is how are we seeing the restart sequence ?shall we (1) restart from inside a set of pre established namespaces or (2) restore the state of the namespaces upon restart ? I think (1) is the best option in semantic, because it's closer to whatthe kernel does: create a directory (a container) and then fill it withfiles (tasks). That's how the cgroup framework works and I have thefeeling we will be using this framework to build the 'super' containerobject. nop ?This direction has an impact on the API because the restart sequence will depend on a set of preliminary settings to create an 'empty' container which can then be used to exec() tasks or restart() tasks. This is a very different API than a magical restart() syscall creating hundreds of namespaces and zillions of tasks from scratch using an opaque binary blob. less attractive for sure but it feels more kernel friendly :)But, may be you have addressed this topic at the summit and the questionis closed ?C.