[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48C54DDC.3090704@fr.ibm.com>
Date: Mon, 08 Sep 2008 18:07:56 +0200
From: Cedric Le Goater <clg@...ibm.com>
To: Andrey Mirkin <amirkin@...allels.com>
CC: devel@...nvz.org, jeremy@...p.org, arnd@...db.de,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, dave@...ux.vnet.ibm.com,
Andrey Mirkin <major@...nvz.org>
Subject: Re: [Devel] Re: [RFC v3][PATCH 1/9] Create syscalls: sys_checkpoint,
sys_restart
>>> --- /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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists