>>> --- /dev/null
quoted text
>>> +++ 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 what
the kernel does:  create a directory (a container) and then fill it with
files (tasks). That's how the cgroup framework works and I have the
feeling we will be using this framework to build the 'super' container
object. 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 question
is closed ?

C. 
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/