From: Andrew Morton <akpm@linux-foundation.org>
To: SeongJae Park <sj@kernel.org>
Cc: shy828301@gmail.com, ziy@nvidia.com, ying.huang@intel.com,
willy@infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] migrate: Wrap CONFIG_DEVICE_PRIVATE dependent function declarations with ifdef
Date: Fri, 11 Feb 2022 13:53:19 -0800 [thread overview]
Message-ID: <20220211135319.1ff408fa6a7c5c5755ac2c87@linux-foundation.org> (raw)
In-Reply-To: <20220209094753.22022-1-sj@kernel.org>
On Wed, 9 Feb 2022 09:47:53 +0000 SeongJae Park <sj@kernel.org> wrote:
> 'migrate_vma_{setup,pages,finalize}()' functions are defined under
> CONFIG_DEVICE_PRIVATE, but their declarations are not. This commit
> wraps the declaration under the config to minimize confusion.
>
> ...
>
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -162,9 +162,14 @@ struct migrate_vma {
> unsigned long flags;
> };
>
> +#ifdef CONFIG_DEVICE_PRIVATE
> +
> int migrate_vma_setup(struct migrate_vma *args);
> void migrate_vma_pages(struct migrate_vma *migrate);
> void migrate_vma_finalize(struct migrate_vma *migrate);
> +
> +#endif /* CONFIG_DEVICE_PRIVATE */
> +
We often don't do this. The advantage is that errors are revealed at
compile time rather than at link time. But the downside is quite a lot
of maintenance overhead and messier-looking header files.
And that maintenance overhead is significant, partly because we can get
this wrong but the kernel will still happily compile and boot! So the
only way to maintain these things is by inspection.
prev parent reply other threads:[~2022-02-11 21:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 9:47 SeongJae Park
2022-02-11 21:53 ` Andrew Morton [this message]
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=20220211135319.1ff408fa6a7c5c5755ac2c87@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shy828301@gmail.com \
--cc=sj@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=ziy@nvidia.com \
/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
all inboxes | Powered by JetHome®