From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:55102 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726400AbeJOVDW (ORCPT ); Mon, 15 Oct 2018 17:03:22 -0400 Date: Mon, 15 Oct 2018 06:18:03 -0700 From: Matthew Wilcox Subject: Re: [PATCH 07/25] vfs: combine the clone and dedupe into a single remap_file_range Message-ID: <20181015131803.GA9845@bombadil.infradead.org> References: <153938912912.8361.13446310416406388958.stgit@magnolia> <153938919123.8361.13059492965161549195.stgit@magnolia> <20181014171927.GD30673@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181014171927.GD30673@infradead.org> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Christoph Hellwig Cc: "Darrick J. Wong" , david@fromorbit.com, sandeen@redhat.com, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, Amir Goldstein , linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, ocfs2-devel@oss.oracle.com 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.