On Sun, Oct 14, 2018 at 10:19:27AM -0700, Christoph Hellwig wrote: > > unsigned (*mmap_capabilities)(struct file *); > > #endif > > ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, loff_t, size_t, unsigned int); > > - int (*clone_file_range)(struct file *, loff_t, struct file *, loff_t, u64); > > - int (*dedupe_file_range)(struct file *, loff_t, struct file *, loff_t, u64); > > + int (*remap_file_range)(struct file *file_in, loff_t pos_in, > > + struct file *file_out, loff_t pos_out, > > + u64 len, unsigned int remap_flags); > > None of the other methods in this file name their parameters. While > I generally don't like people leaving them out, in the end consistency > is even more important. I would agree with you *except* that the parameters do not follow memcpy() traditional order (dst, src, len). Instead they are (src, dst, len), so we should probably name them to advise the poor sod who has to implement this that we've chosen an inconsistent API. Or we could fix it.
