Re: [PATCH v1 10/21] powerpc/kexec: refactor for kernel/Kconfig.kexec
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Eric DeVolder <eric.devolder@xxxxxxxxxx>, linux@xxxxxxxxxxxxxxx, catalin.marinas@xxxxxxx, will@xxxxxxxxxx, chenhuacai@xxxxxxxxxx, geert@xxxxxxxxxxxxxx, tsbogend@xxxxxxxxxxxxxxxx, James.Bottomley@xxxxxxxxxxxxxxxxxxxxx, deller@xxxxxx, ysato@xxxxxxxxxxxxx, dalias@xxxxxxxx, glaubitz@xxxxxxxxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, mingo@xxxxxxxxxx, bp@xxxxxxxxx, dave.hansen@xxxxxxxxxxxxxxx, 86@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, loongarch@xxxxxxxxxxxxxxx, linux-m68k@xxxxxxxxxxxxxxx, linux-mips@xxxxxxxxxxxxxxx, linux-parisc@xxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, linux-riscv@xxxxxxxxxxxxxxxxxxx, linux-s390@xxxxxxxxxxxxxxx, linux-sh@xxxxxxxxxxxxxxx
- Subject: Re: [PATCH v1 10/21] powerpc/kexec: refactor for kernel/Kconfig.kexec
- From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
- Date: Thu, 15 Jun 2023 13:34:25 +1000
- Cc: kernel@xxxxxxxxxx, npiggin@xxxxxxxxx, christophe.leroy@xxxxxxxxxx, paul.walmsley@xxxxxxxxxx, palmer@xxxxxxxxxxx, aou@xxxxxxxxxxxxxxxxx, hca@xxxxxxxxxxxxx, gor@xxxxxxxxxxxxx, agordeev@xxxxxxxxxxxxx, borntraeger@xxxxxxxxxxxxx, svens@xxxxxxxxxxxxx, hpa@xxxxxxxxx, keescook@xxxxxxxxxxxx, paulmck@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, frederic@xxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, ardb@xxxxxxxxxx, samitolvanen@xxxxxxxxxx, juerg.haefliger@xxxxxxxxxxxxx, arnd@xxxxxxxx, rmk+kernel@xxxxxxxxxxxxxxx, linus.walleij@xxxxxxxxxx, sebastian.reichel@xxxxxxxxxxxxx, rppt@xxxxxxxxxx, kirill.shutemov@xxxxxxxxxxxxxxx, anshuman.khandual@xxxxxxx, ziy@xxxxxxxxxx, masahiroy@xxxxxxxxxx, ndesaulniers@xxxxxxxxxx, mhiramat@xxxxxxxxxx, ojeda@xxxxxxxxxx, thunder.leizhen@xxxxxxxxxx, xin3.li@xxxxxxxxx, tj@xxxxxxxxxx, gregkh@xxxxxxxxxxxxxxxxxxx, tsi@xxxxxxxxxx, bhe@xxxxxxxxxx, hbathini@xxxxxxxxxxxxx, sourabhjain@xxxxxxxxxxxxx, eric.devolder@xxxxxxxxxx, boris.ostrovsky@xxxxxxxxxx, konrad.wilk@xxxxxxxxxx
- In-reply-to: <20230612172805.681179-11-eric.devolder@oracle.com>
- References: <20230612172805.681179-1-eric.devolder@oracle.com> <20230612172805.681179-11-eric.devolder@oracle.com>
Eric DeVolder <eric.devolder@xxxxxxxxxx> writes:
> The kexec and crash kernel options are provided in the common
> kernel/Kconfig.kexec. Utilize the common options and provide
> the ARCH_HAS_ and ARCH_SUPPORTS_ entries to recreate the
> equivalent set of KEXEC and CRASH options.
>
> Signed-off-by: Eric DeVolder <eric.devolder@xxxxxxxxxx>
> Reviewed-by: Sourabh Jain <sourabhjain@xxxxxxxxxxxxx>
> ---
> arch/powerpc/Kconfig | 55 ++++++++++++++------------------------------
> 1 file changed, 17 insertions(+), 38 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index bff5820b7cda..36f2fe0cc8a5 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -588,41 +588,21 @@ config PPC64_SUPPORTS_MEMORY_FAILURE
> default "y" if PPC_POWERNV
> select ARCH_SUPPORTS_MEMORY_FAILURE
>
> -config KEXEC
> - bool "kexec system call"
> - depends on PPC_BOOK3S || PPC_E500 || (44x && !SMP)
> - select KEXEC_CORE
> - help
> - kexec is a system call that implements the ability to shutdown your
> - current kernel, and to start another kernel. It is like a reboot
> - but it is independent of the system firmware. And like a reboot
> - you can start any kernel with it, not just Linux.
> -
> - The name comes from the similarity to the exec system call.
> -
> - It is an ongoing process to be certain the hardware in a machine
> - is properly shutdown, so do not be surprised if this code does not
> - initially work for you. As of this writing the exact hardware
> - interface is strongly in flux, so no good recommendation can be
> - made.
> -
> -config KEXEC_FILE
> - bool "kexec file based system call"
> - select KEXEC_CORE
> - select HAVE_IMA_KEXEC if IMA
> - select KEXEC_ELF
> - depends on PPC64
> - depends on CRYPTO=y
> - depends on CRYPTO_SHA256=y
...
> +
> +config ARCH_HAS_KEXEC_FILE
> + def_bool PPC64 && CRYPTO && CRYPTO_SHA256
The =y's got lost here.
I think they were both meaningful, because both options are tristate. So
this previously required them to be built-in (=y), whereas after your
patch it will allow them to be modules.
I don't know for sure that those options need to be built-in, but that's
what the code does now, so this patch shouldn't change it, at least
without an explanation.
cheers
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]