From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: akpm@linux-foundation.org, torvalds@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/2] vfs: move the clone/dedupe/remap helpers to a single file
Date: Thu, 15 Oct 2020 09:46:56 -0700 [thread overview]
Message-ID: <20201015164656.GC9825@magnolia> (raw)
In-Reply-To: <20201015031819.GN3576660@ZenIV.linux.org.uk>
On Thu, Oct 15, 2020 at 04:18:19AM +0100, Al Viro wrote:
> On Wed, Oct 14, 2020 at 05:31:14PM -0700, Darrick J. Wong wrote:
>
> > AFAICT, nobody is attempting to land any major changes in any of the vfs
> > remap functions during the 5.10 window -- for-next showed conflicts only
> > in the Makefile, so it seems like a quiet enough time to do this. There
> > are no functional changes here, it's just moving code blocks around.
> >
> > So, I have a few questions, particularly for Al, Andrew, and Linus:
> >
> > (1) Do you find this reorganizing acceptable?
>
> No objections, assuming that it's really a move (it's surprisingly easy to
> screw that up - BTDT ;-/)
>
> I have not done function-by-function comparison, but assuming it holds...
> no problem.
<nod> The only changes between before and after are that some of the
functions lose their static status, and some gain it; and a minor
indenting issue that I'll fix for the final patch series.
As far as makefiles go, both read_write.o and filemap.o are both obj-y
targets, so I think it's safe to make remap_range.o also an obj-y
target. The fun part will be the careful Kconfig surgery to make
remap_range.o an optional build target, but that will come later.
> > (2) I was planning to rebase this series next Friday and try to throw it
> > in at the end of the merge window; is that ok? (The current patches are
> > based on 5.9, and applying them manually to current master and for-next
> > didn't show any new conflicts.)
>
> Up to Linus. I don't have anything in vfs.git around that area; the
> only remaining stuff touching fs/read_write.c is nowhere near those,
> AFAICS.
<nod> Thanks. :)
--D
next prev parent reply other threads:[~2020-10-15 16:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 0:31 [PATCH 0/2] vfs: move the clone/dedupe/remap helpers to a single file Darrick J. Wong
2020-10-15 0:31 ` [PATCH 1/2] vfs: move generic_remap_checks out of mm Darrick J. Wong
2020-10-15 11:38 ` Matthew Wilcox
2020-10-15 16:39 ` Darrick J. Wong
2020-10-15 0:31 ` [PATCH 2/2] vfs: move the remap range helpers to remap_range.c Darrick J. Wong
2020-10-15 2:48 ` [PATCH 0/2] vfs: move the clone/dedupe/remap helpers to a single file Linus Torvalds
2020-10-15 3:18 ` Al Viro
2020-10-15 16:46 ` Darrick J. Wong [this message]
2020-10-15 16:42 ` [PATCH 3/2] vfs: move the generic write and copy checks out of mm Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201015164656.GC9825@magnolia \
--to=darrick.wong@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.