Re: [Devel] containers mini-summit?

2007-08-15 Thread Oren Laadan
Hi all, [very brief intro: I'm with the Zap project; finally have time to join the discussions after a short period of passively watching the list] There is a good chance I'll be passing nearby, and that would be an excellent opportunity for me to personally meet those who plan to attend, as

[Devel] Re: [RFC] Container mini-summit agenda for Sept 3, 2007

2007-08-31 Thread Oren Laadan
Cedric Le Goater wrote: Hello Oren, Oren Laadan wrote: Cedric Le Goater wrote: Hello All, Some of us will meet next week for the first mini-summit on containers. Many thanks to Alasdair Kergon and LCE for the help they provided in making this mini-summit happen ! It will be help

[Devel] Re: [DRAFT] Container mini-summit notes v0.01

2007-09-26 Thread Oren Laadan
(sorry from the delay, been away :) Eric W. Biederman wrote: Serge E. Hallyn [EMAIL PROTECTED] writes: Sorry, I was focusing on the virtual server needs. devpts is it's own fs so I was fully expecting to make it mountable multiple times so a container can have it's own /dev/pts/0. So

[Devel] Re: [DRAFT] Container mini-summit notes v0.01

2007-10-29 Thread Oren Laadan
[EMAIL PROTECTED] wrote: Oren Laadan [EMAIL PROTECTED] wrote: | | (sorry from the delay, been away :) | | Eric W. Biederman wrote: | Serge E. Hallyn [EMAIL PROTECTED] writes: | | Sorry, I was focusing on the virtual server needs. | | devpts is it's own fs so I was fully expecting

[Devel] Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Oren Laadan
I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside that container ? Since anyway we will have to keep a white- (or

[Devel] Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-17 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file, or via fuse), and that file system already has a device that we would like to ban inside

[Devel] Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-19 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file system (eg. nfs, usb, loop mount from a file

[Devel] Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

2007-12-20 Thread Oren Laadan
Pavel Emelyanov wrote: Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I hate to bring this again, but what if the admin in the container mounts an external file

[Devel] Re: Namespaces exhausted CLONE_XXX bits problem

2008-01-14 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Cedric Le Goater ([EMAIL PROTECTED]): to be more precise : long sys_clone_something(struct clone_something_args args) and long sys_unshare_something(struct unshare_something_args

[Devel] Re: [PATCH] An attempt to have an unlimitedly extendable sys_clone

2008-01-15 Thread Oren Laadan
Pavel Emelyanov wrote: We have one bit in the clone_flags left, so we won't be able to create more namespaces after we make it busy. Besides, for checkpoint/restart jobs we might want to create tasks with pre-defined pids (virtual of course). What else might be required from clone() -

[Devel] Re: [PATCH 2.6.24-rc8-mm1 09/15] (RFC) IPC: new kernel API to change an ID

2008-02-05 Thread Oren Laadan
I strongly second Kirill on this matter. IMHO, we should _avoid_ as much as possible exposing internal kernel state to applications, unless a _real_ need for it is _clearly_ demonstrated. The reasons for this are quite obvious. It isn't strictly necessary to export a new interface in order to

[Devel] Re: [PATCH 2.6.24-rc8-mm1 09/15] (RFC) IPC: new kernel API to change an ID

2008-02-05 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): I strongly second Kirill on this matter. IMHO, we should _avoid_ as much as possible exposing internal kernel state to applications, unless a _real_ need for it is _clearly_ demonstrated. The reasons for this are quite obvious

Re: [Devel] [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts

2008-02-06 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): [EMAIL PROTECTED] wrote: From: Sukadev Bhattiprolu [EMAIL PROTECTED] Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts [SNIP] That stuff

Re: [Devel] [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts

2008-02-06 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): [EMAIL PROTECTED] wrote: From: Sukadev Bhattiprolu [EMAIL PROTECTED] Subject: [RFC

Re: [Devel] [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts

2008-02-11 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Pavel Emelyanov ([EMAIL PROTECTED]): [EMAIL PROTECTED

[Devel] Re: [RFC][PATCH 4/4] PID: use the target ID specified in procfs

2008-03-13 Thread Oren Laadan
Eric W. Biederman wrote: Nadia Derbey [EMAIL PROTECTED] writes: Eric W. Biederman wrote: Nadia Derbey [EMAIL PROTECTED] writes: A couple of weeks ago, a discussion has started after Pierre's proposal for a new syscall to change an ipc id (see thread http://lkml.org/lkml/2008/1/29/209).

[Devel] Re: [RFC][PATCH 0/4] Object creation with a specified id

2008-03-14 Thread Oren Laadan
Pavel Emelyanov wrote: Oren Laadan wrote: Nadia Derbey wrote: Oren Laadan wrote: [EMAIL PROTECTED] wrote: A couple of weeks ago, a discussion has started after Pierre's proposal for a new syscall to change an ipc id (see thread http://lkml.org/lkml/2008/1/29/209). Oren's suggestion

[Devel] Re: [RFC][PATCH 0/4] Object creation with a specified id

2008-03-14 Thread Oren Laadan
Nadia Derbey wrote: Oren Laadan wrote: Nadia Derbey wrote: Oren Laadan wrote: [EMAIL PROTECTED] wrote: A couple of weeks ago, a discussion has started after Pierre's proposal for a new syscall to change an ipc id (see thread http://lkml.org/lkml/2008/1/29/209). Oren's

[Devel] Re: [RFC][PATCH 1/4] Provide a new procfs interface to set next id

2008-03-28 Thread Oren Laadan
On Fri, 28 Mar 2008, [EMAIL PROTECTED] wrote: [PATCH 01/04] This patch proposes the procfs facilities needed to feed the id for the next object to be allocated. if an echo LONG XX /proc/self/next_id is issued, next object to be created will have XX as its id. This applies to objects

[Devel] Re: [RFC][PATCH 0/4] Object creation with a pre-defined id (v2)

2008-03-28 Thread Oren Laadan
On Fri, 28 Mar 2008, [EMAIL PROTECTED] wrote: Hi, Here is a second version of what has been proposed 2 weeks ago to create an object with a pre-defined id (this feature would be used during the restart operation) - see thread

[Devel] Re: [RFC][PATCH 0/4] Object creation with a pre-defined id (v2)

2008-03-28 Thread Oren Laadan
On Fri, 28 Mar 2008, [EMAIL PROTECTED] wrote: Hi, Here is a second version of what has been proposed 2 weeks ago to create an object with a pre-defined id (this feature would be used during the restart operation) - see thread

Re: [Devel] [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer

2008-04-04 Thread Oren Laadan
Matt Helsley wrote: On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote: On Thu, Apr 3, 2008 at 2:03 PM, [EMAIL PROTECTED] wrote: * freezer.kill writing n will send signal number n to all tasks My first thought (not having looked at the code yet) is that sending a signal

Re: [Devel] [RFC PATCH 0/4] Container Freezer: Reuse Suspend Freezer

2008-04-04 Thread Oren Laadan
Matt Helsley wrote: On Fri, 2008-04-04 at 11:56 -0400, Oren Laadan wrote: Matt Helsley wrote: On Thu, 2008-04-03 at 16:49 -0700, Paul Menage wrote: On Thu, Apr 3, 2008 at 2:03 PM, [EMAIL PROTECTED] wrote: * freezer.kill writing n will send signal number n to all tasks My first

[Devel] Re: [RFC][PATCH 0/4] Object creation with a specified id

2008-04-15 Thread Oren Laadan
Nadia Derbey wrote: Nick Andrew wrote: On Fri, Apr 04, 2008 at 04:51:29PM +0200, [EMAIL PROTECTED] wrote: . echo LONG XX /proc/self/next_id next object to be created will have an id set to XX . echo LONGn X0 ... Xn-1 /proc/self/next_id next object to be created will have its

[Devel] Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)

2008-04-23 Thread Oren Laadan
Kirill Korotaev wrote: If the current interface is insufficient, we should first expand it in such a way that it can be used for checkpoint. That certainly won't work in all cases. fork(), for instance, doesn't take any arguments and is going to be awfully hard to expand. :) I'd love to

[Devel] Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)

2008-04-24 Thread Oren Laadan
Dave Hansen wrote: On Thu, 2008-04-24 at 11:00 +0400, Kirill Korotaev wrote: Yeah... we talked with Andrew yesterday. He mostly agrees with a black box. He also said an interesting idea, that if you need compatibility between the kernels (like we for example, support for migration from

[Devel] Re: [RFC][PATCH][cryo] Save/restore state of unnamed pipes

2008-06-22 Thread Oren Laadan
[EMAIL PROTECTED] wrote: From fd13986de32af31621b1badbcf7bfb5626648e0e Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu [EMAIL PROTECTED] Date: Mon, 16 Jun 2008 18:41:05 -0700 Subject: [PATCH] Save/restore state of unnamed pipes Design: Current Linux kernels provide ability to

[Devel] Re: [RFC PATCH 0/5] Resend - Use procfs to change a syscall behavior

2008-07-17 Thread Oren Laadan
Wow ... the volume of messages in this thread is overwhelming. I guess it had to happen when I was off a month long vacation ! Ok .. lemme see if I can catch up: Serge E. Hallyn wrote: Quoting Pavel Machek ([EMAIL PROTECTED]): An alternative to this solution consists in defining a new field

Re: [Devel] [RFC PATCH 0/5] Resend -v2 - Use procfs to change a syscall behavior

2008-07-17 Thread Oren Laadan
Eric W. Biederman wrote: Alexey Dobriyan [EMAIL PROTECTED] writes: I seem to not have received any of Alexey's emails... ? On Tue, Jul 08, 2008 at 01:24:22PM +0200, [EMAIL PROTECTED] wrote: # echo LONG1 XX /proc/self/task/my_tid/next_syscall_data Same stuff. There is struct

[Devel] Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)

2008-07-17 Thread Oren Laadan
Eric W. Biederman wrote: Oren Laadan [EMAIL PROTECTED] writes: Consider more intimate kernel states like: a. task statistics b. task start time c. load average d. skb state and it's data. e. mount tree. If you think over, e.g. (b) is a bad thing. It was used to be accounted

[Devel] Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)

2008-07-17 Thread Oren Laadan
Dave Hansen wrote: On Wed, 2008-07-09 at 18:58 -0700, Eric W. Biederman wrote: In the worst case today we can restore a checkpoint by replaying all of the user space actions that took us to get there. That is a tedious and slow approach. Yes, tedious and slow, *and* minimally invasive in

[Devel] Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)

2008-07-17 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Dave Hansen ([EMAIL PROTECTED]): On Wed, 2008-07-09 at 18:58 -0700, Eric W. Biederman wrote: In the worst case today we can restore a checkpoint by replaying all of the user space actions that took us to get there. That is a tedious and slow approach. Yes,

[Devel] Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)

2008-07-17 Thread Oren Laadan
Dave Hansen wrote: On Thu, 2008-07-10 at 12:21 -0700, Eric W. Biederman wrote: Are we talking about the VMA itself, or the memory backing the VMA? The memory backing the VMA. We need to store the page protections that the memory was mapped with as well now that you point it out. A VMA is

[Devel] Re: [BUG][cryo] Create file on restart ?

2008-07-17 Thread Oren Laadan
[EMAIL PROTECTED] wrote: Serge E. Hallyn [EMAIL PROTECTED] wrote: | Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): | Serge E. Hallyn [EMAIL PROTECTED] wrote: | | Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): | | | | cryo does not (cannot ?) recreate files if the application created

[Devel] Re: [BUG][cryo] Create file on restart ?

2008-07-17 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Matt Helsley ([EMAIL PROTECTED]): On Wed, 2008-07-16 at 14:26 -0700, [EMAIL PROTECTED] wrote: Serge E. Hallyn [EMAIL PROTECTED] wrote: | Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): | Serge E. Hallyn [EMAIL PROTECTED] wrote: | | Quoting [EMAIL PROTECTED]

[Devel] Re: Roadmap for features planed for containers where and Some future features ideas.

2008-07-22 Thread Oren Laadan
Eric W. Biederman wrote: Peter Dolding [EMAIL PROTECTED] writes: On Mon, Jul 21, 2008 at 10:13 PM, Eric W. Biederman [EMAIL PROTECTED] wrote: Peter Dolding [EMAIL PROTECTED] writes: http://opensolaris.org/os/community/brandz/ I would like to see if something equal to this is on the

[Devel] Re: C/R minisummit notes

2008-07-23 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Daniel Lezcano ([EMAIL PROTECTED]): * What are the problems that the linux community can solve with the checkpoint/restart ? Eric Biederman reminds at the previous OLS nobody complained about the checkpoint/restart Pavel Emylianov : The

[Devel] Re: Roadmap for features planed for containers where and Some future features ideas.

2008-07-24 Thread Oren Laadan
Peter Dolding wrote: On Wed, Jul 23, 2008 at 12:05 AM, Oren Laadan [EMAIL PROTECTED] wrote: Eric W. Biederman wrote: Peter Dolding [EMAIL PROTECTED] writes: On Mon, Jul 21, 2008 at 10:13 PM, Eric W. Biederman [EMAIL PROTECTED] wrote: Peter Dolding [EMAIL PROTECTED] writes: http

[Devel] Re: Containers Digest, Vol 24, Issue 82

2008-07-24 Thread Oren Laadan
Peter Dolding wrote: Daniel Lezcano [EMAIL PROTECTED] writes: * What are the problems that the linux community can solve with the checkpoint/restart ? EB : Better to add a little CR functionnality into the kernel itself and add more after. DLu : Problem with kernel version

[Devel] Re: C/R minisummit notes

2008-07-24 Thread Oren Laadan
Let's have some more breakfast, tomorrow - Friday - morning. Same place, same time. If it doesn't rain we'll go outside ;) Oren. ___ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers

[Devel] Re: C/R minisummit notes (namespace naming)

2008-07-25 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Daniel Lezcano ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Eric W. Biederman ([EMAIL PROTECTED]): Currently we have three possibilities on how to name pid namespaces. - indirect via processes - pids - names in the filesystem We discussed this a bit

[Devel] [RFC][PATCH 0/2] CR: save/restore a single, simple task

2008-07-29 Thread Oren Laadan
In the recent mini-summit at OLS 2008 and the following days it was agreed to tackle the checkpoint/restart (CR) by beginning with a very simple case: save and restore a single task, with simple memory layout, disregarding other task state such as files, signals etc. Following these discussions

[Devel] [RFC][PATCH 1/2] CR: introduce sys_checkpoint and sys_restore

2008-07-29 Thread Oren Laadan
the first argument identifies the target container; for sys_restart it will identify the checkpoint image. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- Makefile |2 +- arch/x86/kernel/syscall_table_32.S |2 ++ include/asm-x86/unistd_32.h|2

[Devel] [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-29 Thread Oren Laadan
by the caller (sys.c), alloc/setup/free of the checkpoint/restart context (sys.c), output wrappers and basic checkpoint handling (checkpoint.c), memory dump (ckpt_mem.c), input wrappers and basic restart handling (restart.c), and finally the memory restore (rstr_mem.c). Signed-off-by: Oren Laadan

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-30 Thread Oren Laadan
(rstr_mem.c). Signed-off-by: Oren Laadan [EMAIL PROTECTED] please write a documentation of describe memory dump file format, and split save and restore to two patches. While save and restore functionality is already split to different source files, I can easily refine the patch. Dump file

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-30 Thread Oren Laadan
Louis Rilling wrote: Hi Oren, On Tue, Jul 29, 2008 at 11:27:17PM -0400, Oren Laadan wrote: Expand the template sys_checkpoint and sys_restart to be able to dump and restore a single task. The task's address space may consist of only private, simple vma's - anonymous or file-mapped

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-30 Thread Oren Laadan
Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): +int do_checkpoint(struct cr_ctx *ctx) +{ +int ret; + +/* FIX: need to test whether container is checkpointable */ + +ret = cr_write_hdr(ctx); +if (!ret) +ret = cr_write_task(ctx, current

[Devel] Re: [RFC][PATCH 0/2] CR: save/restore a single, simple task

2008-07-30 Thread Oren Laadan
Disclaimer: long reply :) Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): In the recent mini-summit at OLS 2008 and the following days it was agreed to tackle the checkpoint/restart (CR) by beginning with a very simple case: save and restore a single task, with simple memory

[Devel] Re: [RFC][PATCH 0/2] CR: save/restore a single, simple task

2008-07-30 Thread Oren Laadan
Dave Hansen wrote: On Wed, 2008-07-30 at 16:35 -0500, Serge E. Hallyn wrote: So task 5 created its mm_struct, task 6 is supposed to use the same mm_struct, so it finds that out from the context? I wonder whether that would start to become complicated when checkpointing nested containers.

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-31 Thread Oren Laadan
Louis Rilling wrote: On Wed, Jul 30, 2008 at 02:27:52PM -0400, Oren Laadan wrote: Louis Rilling wrote: +/** + * cr_vma_fill_pgarr - fill a page-array with addr/page tuples for a vma + * @ctx - checkpoint context + * @pgarr - page-array to fill + * @vma - vma to scan + * @start - start

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-31 Thread Oren Laadan
Louis Rilling wrote: On Wed, Jul 30, 2008 at 06:20:32PM -0400, Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): +int do_checkpoint(struct cr_ctx *ctx) +{ + int ret; + + /* FIX: need to test whether container is checkpointable */ + + ret

[Devel] Re: [RFC][PATCH 0/2] CR: save/restore a single, simple task

2008-07-31 Thread Oren Laadan
Daniel Lezcano wrote: Oren Laadan wrote: Disclaimer: long reply :) Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): In the recent mini-summit at OLS 2008 and the following days it was agreed to tackle the checkpoint/restart (CR) by beginning with a very simple case: save

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-31 Thread Oren Laadan
Louis Rilling wrote: On Thu, Jul 31, 2008 at 11:09:54AM -0400, Oren Laadan wrote: Louis Rilling wrote: On Wed, Jul 30, 2008 at 06:20:32PM -0400, Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan ([EMAIL PROTECTED]): +int do_checkpoint(struct cr_ctx *ctx) +{ +int ret

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-07-31 Thread Oren Laadan
Louis Rilling wrote: On Thu, Jul 31, 2008 at 12:28:57PM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008 at 11:09:54AM -0400, Oren Laadan wrote: Louis Rilling wrote: On Wed, Jul 30, 2008 at 06:20:32PM -0400, Oren Laadan wrote: Serge E. Hallyn wrote: Quoting Oren Laadan

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-08-01 Thread Oren Laadan
Louis Rilling wrote: On Thu, Jul 31, 2008 at 03:12:32PM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008 at 12:28:57PM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008 at 11:09:54AM -0400, Oren Laadan wrote: Louis Rilling wrote: On Wed, Jul 30, 2008

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-08-01 Thread Oren Laadan
Louis Rilling wrote: On Fri, Aug 01, 2008 at 10:15:26AM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008 at 03:12:32PM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008 at 12:28:57PM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-08-04 Thread Oren Laadan
Louis Rilling wrote: On Fri, Aug 01, 2008 at 02:51:57PM -0400, Oren Laadan wrote: Louis Rilling wrote: On Fri, Aug 01, 2008 at 10:15:26AM -0400, Oren Laadan wrote: Louis Rilling wrote: On Thu, Jul 31, 2008 at 03:12:32PM -0400, Oren Laadan wrote: Cut the less interesting (IMHO at least

[Devel] Re: [RFC][PATCH 2/2] CR: handle a single task with private memory maps

2008-08-05 Thread Oren Laadan
Louis Rilling wrote: On Mon, Aug 04, 2008 at 08:51:37PM -0700, Joseph Ruscio wrote: As somewhat of a tangent to this discussion, I've been giving some thought to the general strategy we talked about during the summit. The checkpointing solution we built at Evergrid sits completely in

[Devel] Re: [RFC][PATCH 0/4] kernel-based checkpoint restart

2008-08-08 Thread Oren Laadan
Hi, Arnd Bergmann wrote: On Friday 08 August 2008, Dave Hansen wrote: These patches are from Oren Laaden. I've refactored them a bit to make them a wee bit more reviewable. I think this separates out the per-arch bits pretty well. It should also be at least build-bisetable. Cool stuff

[Devel] Re: [RFC][PATCH 2/4] checkpoint/restart: x86 support

2008-08-08 Thread Oren Laadan
Hi, Thanks for the feedback. The proof-of-concept is written for x86 32 bits, keeping in mind that we'll need support for 64 bits support. My goal is to leverage feedback and contributions to have support for 64 bits and other architectures as well. Arnd Bergmann wrote: diff -puN /dev/null

[Devel] Re: [RFC][PATCH 4/4] introduce sys_checkpoint and sys_restore

2008-08-08 Thread Oren Laadan
Arnd Bergmann wrote: On Friday 08 August 2008, Dave Hansen wrote: linux-2.6.git-dave/arch/x86/kernel/syscall_table_32.S |2 ++ linux-2.6.git-dave/include/asm-x86/unistd_32.h|2 ++ 2 files changed, 4 insertions(+) System calls should also be declared in

[Devel] Re: [RFC][PATCH 1/4] checkpoint-restart: general infrastructure

2008-08-08 Thread Oren Laadan
Dave Hansen wrote: On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote: On Friday 08 August 2008, Dave Hansen wrote: + hh-magic = 0x00a2d200; + hh-major = (LINUX_VERSION_CODE 16) 0xff; + hh-minor = (LINUX_VERSION_CODE 8) 0xff; + hh-patch = (LINUX_VERSION_CODE) 0xff; ...

[Devel] Re: [RFC][PATCH 2/4] checkpoint/restart: x86 support

2008-08-08 Thread Oren Laadan
Arnd Bergmann wrote: On Friday 08 August 2008, Oren Laadan wrote: It seems weird that you use __u64 members for the registers, but don't include r8..r15 in the list. As a consequence, this structure does not seem well suited for either x86-32 or x86-64. In the context of CR, x86-32

[Devel] Re: [RFC][PATCH 2/4] checkpoint/restart: x86 support

2008-08-08 Thread Oren Laadan
Dave Hansen wrote: On Fri, 2008-08-08 at 19:04 -0400, Oren Laadan wrote: struct pt_regs is part of the kernel ABI, it will not change. I'm in favor about keeping the format identical between the variations of each architecture. Note, however, that struct pt_regs won't do because it may

[Devel] Re: [RFC][PATCH 2/4] checkpoint/restart: x86 support

2008-08-08 Thread Oren Laadan
Dave Hansen wrote: On Fri, 2008-08-08 at 21:20 -0400, Oren Laadan wrote: hehehe .. both; I meant that while it doesn't change per architecture, it varies between architectures. So struct pt_regs compiled for x86-32 is different than that compiled for x86-64. Therefore we can't just dump

[Devel] Re: checkpoint/restart ABI

2008-08-11 Thread Oren Laadan
Quoting Dave Hansen [EMAIL PROTECTED]: Arnd, Jeremy and Oren, Thanks for all of the very interesting comments about the ABI. I second that ! Considering that we're still *really* early in getting this concept merged up into mainline, what do you all think we should do now? My main goal

[Devel] Re: [RFC][PATCH 1/4] checkpoint-restart: general infrastructure

2008-08-11 Thread Oren Laadan
Dave Hansen wrote: On Mon, 2008-08-11 at 12:03 -0600, Jonathan Corbet wrote: I'm trying to figure out this patch set...here's a few things which have caught my eye in passing. +/** + * cr_get_fname - return pathname of a given file + * @file: file pointer + * @buf: buffer for pathname +

[Devel] Re: [RFC][PATCH 1/4] checkpoint-restart: general infrastructure

2008-08-20 Thread Oren Laadan
Pavel Machek wrote: Hi! I have to wonder if this is just a symptom of us trying to do this the wrong way. We're trying to talk the kernel into writing internal gunk into a FD. You're right, it is like a splice where one end of the pipe is in the kernel. Any thoughts on a better way to

[Devel] Re: checkpoint/restart ABI

2008-08-20 Thread Oren Laadan
Jeremy Fitzhardinge wrote: Dave Hansen wrote: I'm not sure what you mean by closed files. Either the app has a fd, it doesn't, or it is in sys_open() somewhere. We have to get the app into a quiescent state before we can checkpoint, so we basically just say that we won't checkpoint things

[Devel] Re: checkpoint/restart ABI

2008-08-20 Thread Oren Laadan
Dave Hansen wrote: On Tue, 2008-08-12 at 09:32 -0700, Jeremy Fitzhardinge wrote: Inter-machine networking stuff is hard because its outside the checkpointed set, so the checkpoint is observable. Migration is easier, in principle, because you might be able to shift the connection endpoint

[Devel] [RFC v2][PATCH 1/9] kernel based checkpoint-restart

2008-08-20 Thread Oren Laadan
These patches implement checkpoint-restart [CR v2]. This version adds save and restore of open files state (regular files and directories) which makes it more usable. Other changes address the feedback given for the previous version. It is also refactored (along Dave's posting) for easier

[Devel] [RFC v2][PATCH 1/9] Create trivial sys_checkpoint/sys_restart syscalls

2008-08-20 Thread Oren Laadan
the first argument identifies the target container; for sys_restart it will identify the checkpoint image. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- arch/x86/kernel/syscall_table_32.S |2 ++ include/asm-x86/unistd_32.h|2 ++ include/linux/syscalls.h |2

[Devel] [RFC v2][PATCH 4/9] Memory management - dump state

2008-08-20 Thread Oren Laadan
) followed by a dump of the contents of all dumped pages (npages pages). Then will come the next VMA and so on. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- checkpoint/Makefile |2 +- checkpoint/checkpoint.c |3 + checkpoint/ckpt.h |6 + checkpoint/ckpt_arch.h |1

[Devel] [RFC v2][PATCH 5/9] Memory managemnet - restore state

2008-08-20 Thread Oren Laadan
Restoring the memory address space begins with nuking the existing one of the current process, and then reading the VMA state and contents. Call do_mmap_pgoffset() for each VMA and then read in the data. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- checkpoint/Makefile|2

[Devel] [RFC v2][PATCH 6/9] Checkpoint/restart: initial documentation

2008-08-20 Thread Oren Laadan
Covers application checkpoint/restart, overall design, interfaces and checkpoint image format. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- Documentation/checkpoint.txt | 177 ++ 1 files changed, 177 insertions(+), 0 deletions(-) create mode

[Devel] [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart

2008-08-20 Thread Oren Laadan
wrappers and basic checkpoint handling ckpt/restart.c - input wrappers and basic restart handling Patches to add the per-architecture support as well as the actual work to do the memory checkpoint follow in subsequent patches. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- Makefile

[Devel] [RFC v2][PATCH 3/9] x86 support for checkpoint/restart

2008-08-20 Thread Oren Laadan
(Following Dave Hansen's refactoring of the original post) Add logic to save and restore architecture specific state, including thread-specific state, CPU registers and FPU state. Currently only x86-32 is supported. Compiling on x86-64 will trigger an explicit error. Signed-off-by: Oren Laadan

[Devel] [RFC v2][PATCH 9/9] File descriprtors (restore)

2008-08-20 Thread Oren Laadan
basic FDs - regular files, directories and also symbolic links. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- checkpoint/Makefile |2 +- checkpoint/checkpoint.c |3 + checkpoint/ckpt.h |6 +- checkpoint/restart.c|3 + checkpoint/rstr_file.c | 202

[Devel] [RFC v2][PATCH 7/9] Infrastructure for shared objects

2008-08-20 Thread Oren Laadan
indexed by its identifier). Otherwise, the object in the hash table is used. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- Documentation/checkpoint.txt | 44 ++ checkpoint/Makefile |2 +- checkpoint/ckpt.h| 18 checkpoint/objhash.c | 193

[Devel] [RFC v2][PATCH 8/9] File descriprtors - dump state

2008-08-20 Thread Oren Laadan
is to be saved (first time) then this is followed by a 'struct cr_hdr_fd_data' with the FD state. Then will come the next FD and so on. This patch only handles basic FDs - regular files, directories and also symbolic links. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- checkpoint/Makefile

[Devel] Re: [RFC v2][PATCH 1/9] kernel based checkpoint-restart

2008-08-20 Thread Oren Laadan
. It is still possible to put the bulk of the code in a module. This is useful, besides reducing debug time (recompile, unload, reload), to reduce the kernel memory footprint. Also, an administrator can load/unload the module to enable/disable this feature. Any thoughts ? Oren. Oren Laadan wrote

[Devel] Re: [RFC v2][PATCH 9/9] File descriprtors (restore)

2008-08-20 Thread Oren Laadan
handles basic FDs - regular files, directories and also symbolic links. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- checkpoint/Makefile |2 +- checkpoint/checkpoint.c |3 + checkpoint/ckpt.h |6 +- checkpoint/restart.c|3 + checkpoint/rstr_file.c | 202

[Devel] Re: [RFC v2][PATCH 1/9] Create trivial sys_checkpoint/sys_restart syscalls

2008-08-20 Thread Oren Laadan
this, of course, should be the last patch, not the first. Oren Laadan wrote: Create trivial sys_checkpoint and sys_restore system calls. They will enable to checkpoint and restart an entire container, to and from a checkpoint image file. First create a template for both syscalls: they take

[Devel] Re: checkpoint/restart ABI

2008-08-21 Thread Oren Laadan
Arnd Bergmann wrote: On Monday 11 August 2008, Dave Hansen wrote: Thanks for all of the very interesting comments about the ABI. Considering that we're still *really* early in getting this concept merged up into mainline, what do you all think we should do now? I think the two most

[Devel] Re: checkpoint/restart ABI

2008-08-21 Thread Oren Laadan
Arnd Bergmann wrote: On Thursday 21 August 2008, Oren Laadan wrote: Using a single handle (crid or a special file descriptor) to identify the whole checkpoint is very useful - to be able to stream it (eg. over the network, or through filters). It is also very important for future features

[Devel] Re: [RFC v2][PATCH 1/9] Create trivial sys_checkpoint/sys_restart syscalls

2008-08-22 Thread Oren Laadan
Dave Hansen wrote: On Wed, 2008-08-20 at 23:03 -0400, Oren Laadan wrote: 6/unistd_32.h index d739467..88bdec4 100644 --- a/include/asm-x86/unistd_32.h +++ b/include/asm-x86/unistd_32.h @@ -338,6 +338,8 @@ #define __NR_dup3 330 #define __NR_pipe2331 #define

[Devel] Re: [RFC v2][PATCH 4/9] Memory management - dump state

2008-08-22 Thread Oren Laadan
Thanks Louis for all the comments. Will fix in v3. Oren. Louis Rilling wrote: On Wed, Aug 20, 2008 at 11:05:15PM -0400, Oren Laadan wrote: For each VMA, there is a 'struct cr_vma'; if the VMA is file-mapped, it will be followed by the file name. The cr_vma-npages will tell how many pages

[Devel] Re: [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart

2008-08-24 Thread Oren Laadan
Louis Rilling wrote: On Wed, Aug 20, 2008 at 11:04:13PM -0400, Oren Laadan wrote: Add those interfaces, as well as helpers needed to easily manage the file format. The code is roughly broken out as follows: ckpt/sys.c - user/kernel data transfer, as well as setup of the checkpoint/restart

[Devel] Re: [RFC v2][PATCH 4/9] Memory management - dump state

2008-08-24 Thread Oren Laadan
Dave Hansen wrote: On Wed, 2008-08-20 at 23:05 -0400, Oren Laadan wrote: index 7ecafb3..0addb63 100644 --- a/checkpoint/ckpt.h +++ b/checkpoint/ckpt.h @@ -29,6 +29,9 @@ struct cr_ctx { void *hbuf; /* header: to avoid many alloc/dealloc */ int hpos; +struct

[Devel] Re: [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart

2008-08-24 Thread Oren Laadan
Dave Hansen wrote: On Wed, 2008-08-20 at 23:04 -0400, Oren Laadan wrote: diff --git a/checkpoint/checkpoint.c b/checkpoint/checkpoint.c new file mode 100644 index 000..25343f5 --- /dev/null +++ b/checkpoint/checkpoint.c [...] +/* write the checkpoint header */ +static int

[Devel] Re: [RFC v2][PATCH 8/9] File descriprtors - dump state

2008-08-24 Thread Oren Laadan
Louis Rilling wrote: On Wed, Aug 20, 2008 at 11:07:16PM -0400, Oren Laadan wrote: Dump the files_struct of a task with 'struct cr_hdr_files', followed by all open file descriptors. Since FDs can be shared, they are assigned a tag and registered in the object hash. For each open FD

[Devel] Re: [RFC v2][PATCH 4/9] Memory management - dump state

2008-08-26 Thread Oren Laadan
Dave Hansen wrote: On Sun, 2008-08-24 at 01:40 -0400, Oren Laadan wrote: +/* vma subtypes */ +enum { + CR_VMA_ANON = 1, + CR_VMA_FILE +}; Is this really necessary, or can we infer it from the contents of the VMA? This classification eventually simplifies both dump and restore

[Devel] Re: [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart

2008-08-26 Thread Oren Laadan
Dave Hansen wrote: On Sun, 2008-08-24 at 22:47 -0400, Oren Laadan wrote: I replaced all of the uses of these with kmalloc()/kfree() and stack allocations. I'm really not sure what these buy us since our allocators are already so fast. tbuf, especially, worries me if it gets used in any

[Devel] Re: linux-2.6-lxc ?

2008-08-31 Thread Oren Laadan
Hi, I have lots of fixes ready to be posted. I will post them most likely by Tuesday night (until which I'm away). No need to hold your breath, but perhaps better to wait until I send them... Oren. Cedric Le Goater wrote: Dave Hansen wrote: On Thu, 2008-08-28 at 17:03 +0200, Cedric Le Goater

[Devel] Re: [RFC v2][PATCH 4/9] Memory management - dump state

2008-08-31 Thread Oren Laadan
Dave, Serge: I'm currently away so I must keep this short. I think we have so far more discussion than an actual problem. I'm happy to coordinate with every interested party to eventually see this work go into main stream. My only concerns are twofold: first, to get more feedback I believe we

[Devel] [RFC v3][PATCH 0/9] Kernel based checkpoint/restart

2008-09-04 Thread Oren Laadan
These patches implement checkpoint-restart [CR v3]. This version is aimed at addressing feedback and eliminating bugs, after having added save and restore of open files state (regular files and directories) which makes it more usable. Todo: - Add support for x86-64 and improve ABI - Refine or

[Devel] [RFC v3][PATCH 1/9] Create syscalls: sys_checkpoint, sys_restart

2008-09-04 Thread Oren Laadan
identifies the target container; for sys_restart it will identify the checkpoint image. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- arch/x86/kernel/syscall_table_32.S |2 ++ checkpoint/Kconfig | 11 +++ checkpoint/Makefile|5 + checkpoint

[Devel] [RFC v3][PATCH 6/9] Checkpoint/restart: initial documentation

2008-09-04 Thread Oren Laadan
Covers application checkpoint/restart, overall design, interfaces and checkpoint image format. Signed-off-by: Oren Laadan [EMAIL PROTECTED] --- Documentation/checkpoint.txt | 182 ++ 1 files changed, 182 insertions(+), 0 deletions(-) create mode

[Devel] [RFC v3][PATCH 3/9] x86 support for checkpoint/restart

2008-09-04 Thread Oren Laadan
(Following Dave Hansen's refactoring of the original post) Add logic to save and restore architecture specific state, including thread-specific state, CPU registers and FPU state. Currently only x86-32 is supported. Compiling on x86-64 will trigger an explicit error. Signed-off-by: Oren Laadan

[Devel] [RFC v3][PATCH 2/9] General infrastructure for checkpoint restart

2008-09-04 Thread Oren Laadan
/checkpoint.c - output wrappers and basic checkpoint handling checkpoint/restart.c - input wrappers and basic restart handling Patches to add the per-architecture support as well as the actual work to do the memory checkpoint follow in subsequent patches. Signed-off-by: Oren Laadan [EMAIL PROTECTED

  1   2   3   4   5   6   7   8   9   10   >