linux-kernel - Re: [Devel] Re: [RFC v3][PATCH 1/9] Create syscalls: sys_checkpoint, sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/