From: Matthew Wilcox <willy@infradead.org>
To: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/5] export __clear_page_buffers to cleanup code
Date: Sun, 19 Apr 2020 14:17:07 -0700 [thread overview]
Message-ID: <20200419211707.GY5820@bombadil.infradead.org> (raw)
In-Reply-To: <e412762b-3121-b69f-2b4b-263e888a171c@cloud.ionos.com>
On Sun, Apr 19, 2020 at 10:31:26PM +0200, Guoqing Jiang wrote:
> On 19.04.20 05:14, Matthew Wilcox wrote:
> > On Sun, Apr 19, 2020 at 12:51:18AM +0200, Guoqing Jiang wrote:
> > > When reading md code, I find md-bitmap.c copies __clear_page_buffers from
> > > buffer.c, and after more search, seems there are some places in fs could
> > > use this function directly. So this patchset tries to export the function
> > > and use it to cleanup code.
> > OK, I see why you did this, but there are a couple of problems with it.
> >
> > One is just a sequencing problem; between exporting __clear_page_buffers()
> > and removing it from the md code, the md code won't build.
>
> Seems the build option BLK_DEV_MD is depended on BLOCK, and buffer.c
> is relied on the same option.
>
> ifeq ($(CONFIG_BLOCK),y)/x
> obj-y += buffer.o block_dev.o direct-io.o mpage.o
> else
> obj-y += no-block.o
> endif
>
> So I am not sure it is necessary to move the function to include/linux/mm.h
> if there is no sequencing problem, thanks for your any further suggestion.
The sequencing problem is that there will be _two_ definitions of
__clear_page_buffers().
The reason it should go in mm.h is that it's a very simple function
and it will be better to inline it than call an external function.
The two things are not related to each other.
next prev parent reply other threads:[~2020-04-19 21:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-18 22:51 [PATCH 0/5] export __clear_page_buffers to cleanup code Guoqing Jiang
2020-04-18 22:51 ` [PATCH 1/5] fs/buffer: export __clear_page_buffers Guoqing Jiang
2020-04-19 7:56 ` Nikolay Borisov
2020-04-19 13:20 ` Guoqing Jiang
2020-04-18 22:51 ` [PATCH 2/5] btrfs: call __clear_page_buffers to simplify code Guoqing Jiang
2020-04-19 19:46 ` David Sterba
2020-04-19 20:32 ` Guoqing Jiang
2020-04-18 22:51 ` [PATCH 3/5] iomap: call __clear_page_buffers in iomap_page_release Guoqing Jiang
2020-04-19 7:47 ` Christoph Hellwig
2020-04-19 13:18 ` Guoqing Jiang
2020-04-18 22:51 ` [RFC PATCH 4/5] orangefs: call __clear_page_buffers to simplify code Guoqing Jiang
2020-04-18 22:51 ` [PATCH 5/5] md-bitmap: don't duplicate code for __clear_page_buffers Guoqing Jiang
2020-04-19 3:14 ` [PATCH 0/5] export __clear_page_buffers to cleanup code Matthew Wilcox
2020-04-19 5:14 ` Gao Xiang
2020-04-19 13:22 ` Guoqing Jiang
2020-04-19 13:15 ` Guoqing Jiang
2020-04-19 20:31 ` Guoqing Jiang
2020-04-19 21:17 ` Matthew Wilcox [this message]
2020-04-19 23:20 ` Dave Chinner
2020-04-20 0:30 ` Matthew Wilcox
2020-04-20 21:14 ` Guoqing Jiang
2020-04-20 22:14 ` Matthew Wilcox
2020-04-21 1:53 ` Dave Chinner
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=20200419211707.GY5820@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=guoqing.jiang@cloud.ionos.com \
--cc=linux-fsdevel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).