Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 20 Jun 2023 22:49:50 +0800
From:   Baoquan He <bhe@redhat.com>
To:     Eric DeVolder <eric.devolder@oracle.com>
Cc:     linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org,
        chenhuacai@kernel.org, geert@linux-m68k.org,
        tsbogend@alpha.franken.de, James.Bottomley@hansenpartnership.com,
        deller@gmx.de, ysato@users.sourceforge.jp, dalias@libc.org,
        glaubitz@physik.fu-berlin.de, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-ia64@vger.kernel.org, loongarch@lists.linux.dev,
        linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
        linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
        linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
        linux-sh@vger.kernel.org, kernel@xen0n.name, mpe@ellerman.id.au,
        npiggin@gmail.com, christophe.leroy@csgroup.eu,
        paul.walmsley@sifive.com, palmer@dabbelt.com,
        aou@eecs.berkeley.edu, hca@linux.ibm.com, gor@linux.ibm.com,
        agordeev@linux.ibm.com, borntraeger@linux.ibm.com,
        svens@linux.ibm.com, hpa@zytor.com, keescook@chromium.org,
        paulmck@kernel.org, peterz@infradead.org, frederic@kernel.org,
        akpm@linux-foundation.org, ardb@kernel.org,
        samitolvanen@google.com, juerg.haefliger@canonical.com,
        arnd@arndb.de, rmk+kernel@armlinux.org.uk,
        linus.walleij@linaro.org, sebastian.reichel@collabora.com,
        rppt@kernel.org, kirill.shutemov@linux.intel.com,
        anshuman.khandual@arm.com, ziy@nvidia.com, masahiroy@kernel.org,
        ndesaulniers@google.com, mhiramat@kernel.org, ojeda@kernel.org,
        thunder.leizhen@huawei.com, xin3.li@intel.com, tj@kernel.org,
        gregkh@linuxfoundation.org, tsi@tuyoix.net, hbathini@linux.ibm.com,
        sourabhjain@linux.ibm.com, boris.ostrovsky@oracle.com,
        konrad.wilk@oracle.com
Subject: Re: [PATCH v2 02/13] x86/kexec: refactor for kernel/Kconfig.kexec
Message-ID: <ZJG8jtNUWXxmnfao@MiWiFi-R3L-srv>
References: <20230619145801.1064716-1-eric.devolder@oracle.com>
 <20230619145801.1064716-3-eric.devolder@oracle.com>
 <ZJFhlsFN6DxnWsQE@MiWiFi-R3L-srv>
 <ac065d02-61a4-3b1f-241d-443ede70d3f2@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ac065d02-61a4-3b1f-241d-443ede70d3f2@oracle.com>
Precedence: bulk

On 06/20/23 at 07:56am, Eric DeVolder wrote:
> 
> 
> On 6/20/23 03:21, Baoquan He wrote:
> > Hi Eric,
> > 
> > On 06/19/23 at 10:57am, Eric DeVolder wrote:
> > ......
> > > +config ARCH_SUPPORTS_KEXEC
> > > +	def_bool y
> > > -config ARCH_HAS_KEXEC_PURGATORY
> > > -	def_bool KEXEC_FILE
> > > +config ARCH_SUPPORTS_KEXEC_FILE
> > > +	def_bool X86_64 && CRYPTO && CRYPTO_SHA256
> > ......
> > > +config ARCH_SELECTS_KEXEC_FILE
> > > +	def_bool y
> > >   	depends on KEXEC_FILE
> > > -	help
> > 
> > I am a little confused about this ARCH_SELECTS_XX adding. Wondering what
> > limits us defining the ARCH_SUPPORTS_KEXEC_FILE like below? I have limited
> > knowledge about Kconfig, please correct me if I am wrong. Thanks in
> > advance.
> > 
> >   +config ARCH_SUPPORTS_KEXEC_FILE
> >   +	def_bool y
> >    	depends on KEXEC_FILE
> >    	depends on X86_64 && CRYPTO && CRYPTO_SHA256
> > 
> 
> For the ARCH_SUPPORTS_ options, I chose to list the dependencies on the
> def_bool line to show that it took all those conditions to result in True.
> However, as you point out, using a def_bool y and then listing them as 'depends on' works as well.
> Probably would have resulted in fewer changes to the Kconfig file.
> Either way is ok (the 'depends on KEXEC_FILE' is erroneous in your example).

Got it, thanks. To me, one option with explicit dependencies looks clearer
and straightforward. I need check and investigage why two options are needed,
whether two options are unavoidable. Not sure if other people would get
the same feeling or not. Honestly, it's my first time to see the usage of
XXX_SELECTS_XXX, it took me a while to dig into.

> 
> > > -
> > > -	  This option makes the kexec_file_load() syscall check for a valid
> > > -	  signature of the kernel image.  The image can still be loaded without
> > > -	  a valid signature unless you also enable KEXEC_SIG_FORCE, though if
> > > -	  there's a signature that we can check, then it must be valid.
> > > -
> > > -	  In addition to this option, you need to enable signature
> > > -	  verification for the corresponding kernel image type being
> > > -	  loaded in order for this to work.
> > > -
> > 
>