[RFC v14-rc2][PATCH 10/29] actually use f_op in checkpoint code

Oren Laadan orenl at cs.columbia.edu
Tue Mar 31 11:31:15 PDT 2009


If ext2/3/4 is compiled as a kernel module, apply this patch to
successfully compile this c/r patchset.

Oren.

diff --git a/checkpoint/ckpt_file.c b/checkpoint/ckpt_file.c
index 0fe68bf..df6bb3d 100644
--- a/checkpoint/ckpt_file.c
+++ b/checkpoint/ckpt_file.c
@@ -109,6 +109,8 @@ int generic_file_checkpoint(struct cr_ctx *ctx, struct file *file,
 	return cr_write_file_generic(ctx, file, hh);
 }
 
+EXPORT_SYMBOL(generic_file_checkpoint);
+
 /* cr_write_file - dump the state of a given file pointer */
 static int cr_write_file(struct cr_ctx *ctx, struct file *file)
 {


On Tue, 31 Mar 2009, Oren Laadan wrote:

> From: Dave Hansen <dave at linux.vnet.ibm.com>
> 
> Right now, we assume all normal files and directories
> can be checkpointed.  However, as usual in the VFS, there
> are specialized places that will always need an ability
> to override these defaults.  We could do this completely
> in the checkpoint code, but that would bitrot quickly.
> 
> This adds a new 'file_operations' function for
> checkpointing a file.  I did this under the assumption
> that we should have a dirt-simple way to make something
> (un)checkpointable that fits in with current code.
> 
> As you can see in the ext[234] and /proc patches, all
> that we have to do to make something simple be
> supported is add a single "generic" f_op entry.
> 
> Signed-off-by: Dave Hansen <dave at linux.vnet.ibm.com>


More information about the Containers mailing list