Serge E. Hallyn wrote: > Quoting Serge E. Hallyn (serue@xxxxxxxxxx): >> Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): >>> From: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> >>> >>> This marks ext[234] as being checkpointable. There will be many >>> more to do this to, but this is a start. >>> >>> Signed-off-by: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> >>> --- >>> fs/ext2/dir.c | 1 + >>> fs/ext2/file.c | 2 ++ >>> fs/ext3/dir.c | 1 + >>> fs/ext3/file.c | 1 + >>> fs/ext4/dir.c | 1 + >>> fs/ext4/file.c | 1 + >>> 6 files changed, 7 insertions(+), 0 deletions(-) >>> >>> diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c >>> index 2999d72..4f1dd79 100644 >>> --- a/fs/ext2/dir.c >>> +++ b/fs/ext2/dir.c >>> @@ -721,4 +721,5 @@ const struct file_operations ext2_dir_operations = { >>> .compat_ioctl = ext2_compat_ioctl, >>> #endif >>> .fsync = ext2_sync_file, >>> + .checkpoint = generic_file_checkpoint, >> The checkpoint() method is only defined in struct file_operations if >> CONFIG_CHECKPOINT=y. So this can't possibly compile when >> CONFIG_CHECKPOINT=n... > > BTW i think the better way to handle it is not to put everything under > ifdefs, but rather always let file_operations have the ->checkpoint() > fn, and just make generic_file_checkpoint() a dummy function when > CONFIG_CHECKPOINT=n. Yes, that's already taken care of (further up in fs.h) in previous patch. It was silly to wrap #ifdef's around the 'checkpoint' field of 'struct file_operations' Thanks, Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers