From: Jisheng Zhang <jszhang@kernel.org>
To: kexec@lists.infradead.org
Subject: [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Date: Tue, 18 Jan 2022 22:13:03 +0800 [thread overview]
Message-ID: <YebK70Sx4w8zLfj/@xhacker> (raw)
In-Reply-To: <20220116133847.GE2388@MiWiFi-R3L-srv>
On Sun, Jan 16, 2022 at 09:38:47PM +0800, Baoquan He wrote:
> Hi Jisheng,
Hi Baoquan,
>
> On 12/07/21 at 12:05am, Jisheng Zhang wrote:
> > Replace the conditional compilation using "#ifdef CONFIG_KEXEC_CORE"
> > by a check for "IS_ENABLED(CONFIG_KEXEC_CORE)", to simplify the code
> > and increase compile coverage.
>
> I go through this patchset, You mention the benefits it brings are
> 1) simplity the code;
> 2) increase compile coverage;
>
> For benefit 1), it mainly removes the dummy function in x86, arm and
> arm64, right?
Another benefit: remove those #ifdef #else #endif usage. Recently, I
fixed a bug due to lots of "#ifdefs":
http://lists.infradead.org/pipermail/linux-riscv/2021-December/010607.html
>
> For benefit 2), increasing compile coverage, could you tell more how it
> achieves and why it matters? What if people disables CONFIG_KEXEC_CORE in
> purpose? Please forgive my poor compiling knowledge.
Just my humble opinion, let's compare the code::
#ifdef CONFIG_KEXEC_CORE
code block A;
#endif
If KEXEC_CORE is disabled, code block A won't be compiled at all, the
preprocessor will remove code block A;
If we convert the code to:
if (IS_ENABLED(CONFIG_KEXEC_CORE)) {
code block A;
}
Even if KEXEC_CORE is disabled, code block A is still compiled.
Thanks
next prev parent reply other threads:[~2022-01-18 14:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-06 16:05 [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef Jisheng Zhang
2021-12-06 16:05 ` [PATCH v2 1/5] kexec: make crashk_res, crashk_low_res and crash_notes symbols always visible Jisheng Zhang
2021-12-06 16:05 ` [PATCH v2 2/5] riscv: mm: init: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef Jisheng Zhang
2022-01-11 17:29 ` Palmer Dabbelt
2021-12-06 16:05 ` [PATCH v2 3/5] x86/setup: " Jisheng Zhang
2021-12-06 16:05 ` [PATCH v2 4/5] arm64: mm: " Jisheng Zhang
2021-12-06 16:05 ` [PATCH v2 5/5] arm: " Jisheng Zhang
2022-01-16 13:38 ` [PATCH v2 0/5] kexec: " Baoquan He
2022-01-18 14:13 ` Jisheng Zhang [this message]
2022-01-19 8:08 ` Baoquan He
2022-01-19 8:52 ` Alexandre Ghiti
2022-01-19 9:33 ` Baoquan He
2022-01-19 11:44 ` Jisheng Zhang
2022-01-20 9:45 ` Baoquan He
2022-01-20 9:50 ` Baoquan He
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=YebK70Sx4w8zLfj/@xhacker \
--to=jszhang@kernel.org \
--cc=kexec@lists.infradead.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).