kexec.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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


  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).