Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn (se...@us.ibm.com):
>> Quoting Oren Laadan (or...@cs.columbia.edu):
>>> From: Dave Hansen <d...@linux.vnet.ibm.com>
>>>
>>> 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 <d...@linux.vnet.ibm.com>
>>> ---
>>> 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
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
