[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220116133847.GE2388@MiWiFi-R3L-srv>
Date: Sun, 16 Jan 2022 21:38:47 +0800
From: Baoquan He <bhe@...hat.com>
To: Jisheng Zhang <jszhang@...nel.org>
Cc: Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
hpa@...or.com, Eric Biederman <ebiederm@...ssion.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, kexec@...ts.infradead.org,
Alexandre ghiti <alex@...ti.fr>
Subject: Re: [PATCH v2 0/5] kexec: use IS_ENABLED(CONFIG_KEXEC_CORE) instead
of #ifdef
Hi Jisheng,
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?
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.
Thanks
Baoquan
Powered by blists - more mailing lists