On Mon, Apr 13, 2009 at 04:47:01PM -0500, Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
Hi Alexey,
as far as I can see, the main differences between this patch and the
equivalent in Oren's tree are:
1. kernel auto-selects container init to freeze
Note,
On Tue, 2009-04-14 at 19:27 +0400, Alexey Dobriyan wrote:
Also, since Dave introduced the fops-checkpoint(), we (or at least I)
have been struck by the ugly assymetry with checkpoint() being in fops,
and restart() not. Do you have an idea for fixing that?
Module can legally support C/R
Quoting Oren Laadan (or...@cs.columbia.edu):
Hi,
Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
Hi Alexey,
as far as I can see, the main differences between this patch and the
equivalent in Oren's tree are:
1. kernel auto-selects container init to
On Tue, Apr 14, 2009 at 01:22:03AM -0400, Oren Laadan wrote:
Alexey Dobriyan wrote:
* add struct file_operations::checkpoint
The point of hook is to serialize enough information to allow restoration
of an opened file.
The idea (good one!) is that the code which supplies
On Tue, 2009-04-14 at 10:41 -0500, Serge E. Hallyn wrote:
Module can legally support C/R for its files.
In the end it most certainly will end up with module registering restart
Which module? The module defining a filesystem?
In that case I'm just not clear on how the restart code will
On Tue, Apr 14, 2009 at 08:41:34AM -0700, Dave Hansen wrote:
On Tue, 2009-04-14 at 19:27 +0400, Alexey Dobriyan wrote:
Also, since Dave introduced the fops-checkpoint(), we (or at least I)
have been struck by the ugly assymetry with checkpoint() being in fops,
and restart() not. Do you
On Tue, Apr 14, 2009 at 10:41:39AM -0500, Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
On Mon, Apr 13, 2009 at 04:47:01PM -0500, Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
Hi Alexey,
as far as I can see, the main differences
On Tue, Apr 14, 2009 at 10:41:39AM -0500, Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
On Mon, Apr 13, 2009 at 04:47:01PM -0500, Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
Hi Alexey,
as far as I can see, the main differences
On Tue, Apr 14, 2009 at 09:39:50AM -0700, Dave Hansen wrote:
On Tue, 2009-04-14 at 20:00 +0400, Alexey Dobriyan wrote:
Are you suggesting that conversion of a checkpoint image from an older
version to a newer version be done in the kernel ?
For mainline kernel it's completely
Alexey Dobriyan wrote:
On Tue, Apr 14, 2009 at 01:22:03AM -0400, Oren Laadan wrote:
Alexey Dobriyan wrote:
* add struct file_operations::checkpoint
The point of hook is to serialize enough information to allow restoration
of an opened file.
The idea (good one!) is that the code
The ability to streamline the checkpoint image IMHO is invaluable.
It's the unix way (TM) of doing things; it makes the process pipe-able.
You can do many nice things when the checkpoint can be streamed: you
can compress, sign, encrypt etc on the fly without taking additional
On Fri, Apr 10, 2009 at 12:19:23PM -0400, Brian Haley wrote:
Alexey Dobriyan wrote:
And of course, I don't want to see multiline
vmflags = ~(VM_READ|VM_WRITE|
[5 lines skipped]
Then why don't you:
#define VM_CR_FOO (VM_READ|VM_WRITE|...)
vmflags =
Quoting Alexey Dobriyan (adobri...@gmail.com):
Hi Alexey,
as far as I can see, the main differences between this patch and the
equivalent in Oren's tree are:
1. kernel auto-selects container init to freeze
2. kernel freezes tasks
3. no objhash taking references
4. no hbuf
5. always require
Alexey Dobriyan wrote:
* add struct file_operations::checkpoint
The point of hook is to serialize enough information to allow restoration
of an opened file.
The idea (good one!) is that the code which supplies struct file_operations
know better what to do with file.
Actually,
Hi,
Serge E. Hallyn wrote:
Quoting Alexey Dobriyan (adobri...@gmail.com):
Hi Alexey,
as far as I can see, the main differences between this patch and the
equivalent in Oren's tree are:
1. kernel auto-selects container init to freeze
Actually, this eliminates the possibility to
* Alexey Dobriyan adobri...@gmail.com wrote:
+int cr_restore_file(struct cr_context *ctx, loff_t pos)
+{
I tried to review this code, but it's almost unreadable to me, due
to basic code structure mistakes like:
+ struct cr_image_file *i, *tmp;
+ struct file *file;
+ struct
On Fri, Apr 10, 2009 at 11:35:20AM +0200, Ingo Molnar wrote:
* Alexey Dobriyan adobri...@gmail.com wrote:
+int cr_restore_file(struct cr_context *ctx, loff_t pos)
+{
I tried to review this code, but it's almost unreadable to me,
Pity you.
due to basic code structure mistakes like:
Alexey Dobriyan wrote:
And of course, I don't want to see multiline
vmflags = ~(VM_READ|VM_WRITE|
[5 lines skipped]
Then why don't you:
#define VM_CR_FOO (VM_READ|VM_WRITE|...)
vmflags = ~VM_CR_FOO;
-Brian
18 matches
Mail list logo
