From: Baoquan He <bhe@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Date: Wed, 19 Jan 2022 16:08:59 +0800 [thread overview]
Message-ID: <20220119080859.GB4977@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YebK70Sx4w8zLfj/@xhacker>
On 01/18/22 at 10:13pm, Jisheng Zhang wrote:
> 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
Glad to know the fix. While, sometime the ifdeffery is necessary. I am
sorry about the one in riscv and you have fixed, it's truly a bug . But,
the increasing compile coverage at below you tried to make, it may cause
issue. Please see below my comment.
>
> >
> > 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.
This is what I am worried about. Before, if CONFIG_KEXEC_CORE is
unset, those relevant codes are not compiled in. I can't see what
benefit is brought in if compiled in the unneeded code block. Do I miss
anything?
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, hpa@zytor.com,
Eric Biederman <ebiederm@xmission.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kexec@lists.infradead.org, Alexandre ghiti <alex@ghiti.fr>
Subject: Re: [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Date: Wed, 19 Jan 2022 16:08:59 +0800 [thread overview]
Message-ID: <20220119080859.GB4977@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YebK70Sx4w8zLfj/@xhacker>
On 01/18/22 at 10:13pm, Jisheng Zhang wrote:
> 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
Glad to know the fix. While, sometime the ifdeffery is necessary. I am
sorry about the one in riscv and you have fixed, it's truly a bug . But,
the increasing compile coverage at below you tried to make, it may cause
issue. Please see below my comment.
>
> >
> > 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.
This is what I am worried about. Before, if CONFIG_KEXEC_CORE is
unset, those relevant codes are not compiled in. I can't see what
benefit is brought in if compiled in the unneeded code block. Do I miss
anything?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, hpa@zytor.com,
Eric Biederman <ebiederm@xmission.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kexec@lists.infradead.org, Alexandre ghiti <alex@ghiti.fr>
Subject: Re: [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Date: Wed, 19 Jan 2022 16:08:59 +0800 [thread overview]
Message-ID: <20220119080859.GB4977@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YebK70Sx4w8zLfj/@xhacker>
On 01/18/22 at 10:13pm, Jisheng Zhang wrote:
> 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
Glad to know the fix. While, sometime the ifdeffery is necessary. I am
sorry about the one in riscv and you have fixed, it's truly a bug . But,
the increasing compile coverage at below you tried to make, it may cause
issue. Please see below my comment.
>
> >
> > 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.
This is what I am worried about. Before, if CONFIG_KEXEC_CORE is
unset, those relevant codes are not compiled in. I can't see what
benefit is brought in if compiled in the unneeded code block. Do I miss
anything?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, hpa@zytor.com,
Eric Biederman <ebiederm@xmission.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
kexec@lists.infradead.org, Alexandre ghiti <alex@ghiti.fr>
Subject: Re: [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead of #ifdef
Date: Wed, 19 Jan 2022 16:08:59 +0800 [thread overview]
Message-ID: <20220119080859.GB4977@MiWiFi-R3L-srv> (raw)
In-Reply-To: <YebK70Sx4w8zLfj/@xhacker>
On 01/18/22 at 10:13pm, Jisheng Zhang wrote:
> 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
Glad to know the fix. While, sometime the ifdeffery is necessary. I am
sorry about the one in riscv and you have fixed, it's truly a bug . But,
the increasing compile coverage at below you tried to make, it may cause
issue. Please see below my comment.
>
> >
> > 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.
This is what I am worried about. Before, if CONFIG_KEXEC_CORE is
unset, those relevant codes are not compiled in. I can't see what
benefit is brought in if compiled in the unneeded code block. Do I miss
anything?
next prev parent reply other threads:[~2022-01-19 8:08 UTC|newest]
Thread overview: 60+ 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 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` 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 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` 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
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2022-01-11 17:29 ` Palmer Dabbelt
2022-01-11 17:29 ` Palmer Dabbelt
2022-01-11 17:29 ` Palmer Dabbelt
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 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` [PATCH v2 4/5] arm64: mm: " Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` [PATCH v2 5/5] arm: " Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2021-12-06 16:05 ` Jisheng Zhang
2022-01-16 13:38 ` [PATCH v2 0/5] kexec: " Baoquan He
2022-01-16 13:38 ` Baoquan He
2022-01-16 13:38 ` Baoquan He
2022-01-16 13:38 ` Baoquan He
2022-01-18 14:13 ` Jisheng Zhang
2022-01-18 14:13 ` Jisheng Zhang
2022-01-18 14:13 ` Jisheng Zhang
2022-01-18 14:13 ` Jisheng Zhang
2022-01-19 8:08 ` Baoquan He [this message]
2022-01-19 8:08 ` Baoquan He
2022-01-19 8:08 ` Baoquan He
2022-01-19 8:08 ` Baoquan He
2022-01-19 8:52 ` Alexandre Ghiti
2022-01-19 8:52 ` Alexandre Ghiti
2022-01-19 8:52 ` Alexandre Ghiti
2022-01-19 8:52 ` Alexandre Ghiti
2022-01-19 9:33 ` Baoquan He
2022-01-19 9:33 ` Baoquan He
2022-01-19 9:33 ` Baoquan He
2022-01-19 9:33 ` Baoquan He
2022-01-19 11:44 ` Jisheng Zhang
2022-01-19 11:44 ` Jisheng Zhang
2022-01-19 11:44 ` Jisheng Zhang
2022-01-19 11:44 ` Jisheng Zhang
2022-01-20 9:45 ` Baoquan He
2022-01-20 9:45 ` Baoquan He
2022-01-20 9:45 ` Baoquan He
2022-01-20 9:45 ` Baoquan He
2022-01-20 9:50 ` Baoquan He
2022-01-20 9:50 ` Baoquan He
2022-01-20 9:50 ` 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=20220119080859.GB4977@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--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 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.