Re: [RFC PATCH 01/35] vfs: clean up dedup
On Thu, Apr 12, 2018 at 6:25 PM, Matthew Wilcoxwrote: > On Thu, Apr 12, 2018 at 05:07:52PM +0200, Miklos Szeredi wrote: >> +ssize_t vfs_dedupe_file_range_one(struct file *src_file, u64 src_pos, u64 >> len, >> + struct file *dst_file, u64 dst_pos) > > Why u64 instead of loff_t? Peculiarity of f_op->dedupe_file_range(). I think a cleanup of copyfile/clone/dedupe interfaces would be good. Perhaps merge them into one? Or just merge copyfile/clone? Even if not merging it should make sense to make argument types and argument order the same. Thanks, Miklos
Re: [RFC PATCH 01/35] vfs: clean up dedup
On Thu, Apr 12, 2018 at 6:25 PM, Matthew Wilcox wrote: > On Thu, Apr 12, 2018 at 05:07:52PM +0200, Miklos Szeredi wrote: >> +ssize_t vfs_dedupe_file_range_one(struct file *src_file, u64 src_pos, u64 >> len, >> + struct file *dst_file, u64 dst_pos) > > Why u64 instead of loff_t? Peculiarity of f_op->dedupe_file_range(). I think a cleanup of copyfile/clone/dedupe interfaces would be good. Perhaps merge them into one? Or just merge copyfile/clone? Even if not merging it should make sense to make argument types and argument order the same. Thanks, Miklos
Re: [RFC PATCH 01/35] vfs: clean up dedup
On Thu, Apr 12, 2018 at 05:07:52PM +0200, Miklos Szeredi wrote: > +ssize_t vfs_dedupe_file_range_one(struct file *src_file, u64 src_pos, u64 > len, > + struct file *dst_file, u64 dst_pos) Why u64 instead of loff_t?
Re: [RFC PATCH 01/35] vfs: clean up dedup
On Thu, Apr 12, 2018 at 05:07:52PM +0200, Miklos Szeredi wrote: > +ssize_t vfs_dedupe_file_range_one(struct file *src_file, u64 src_pos, u64 > len, > + struct file *dst_file, u64 dst_pos) Why u64 instead of loff_t?