Re: [PATCH 020/171] efi: Add a Kconfig for SPL_EFI_LOADER et all

Tom Rini
2023-02-05T02:01:54Z

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

On Sat, Feb 04, 2023 at 06:21:48PM -0700, Simon Glass wrote:
> Hi Tom, Heinrich,
>
> On Mon, 30 Jan 2023 at 07:51, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 30, 2023 at 03:48:44PM +0100, Heinrich Schuchardt wrote:
> > > On 1/30/23 15:40, Simon Glass wrote:
> > > > This and EFI_DEVICE_PATH_TO_TEXT are implicitly used in the source and
> > >
> > > This code is not compiled in SPL. So it cannot be used there.
> > >
> > > > seem useful, so add them.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > ---
> > > >
> > > > lib/efi_loader/Kconfig | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > index 9fe9a2df9ea..0bd42b9e196 100644
> > > > --- a/lib/efi_loader/Kconfig
> > > > +++ b/lib/efi_loader/Kconfig
> > > > @@ -32,6 +32,10 @@ config EFI_LOADER
> > > >
> > > > if EFI_LOADER
> > > >
> > > > +config SPL_EFI_LOADER
> > > > + def_bool n # Support running UEFI applications (SPL)
> > > > + depends on SPL
> > > > +
> > >
> > > I cannot see how this could be used:
> > >
> > > * The size of the EFI code is too big to fit into SPL on most boards.
> >
> > OK, so please do a series to correct all CONFIG_IS_ENABLED(EFI_*) to be
> > IS_ENABLED(CONFIG_EFI_*), other than EFI_PARTITIONS which can be in SPL.
>
> This is another case where I think it is actually needed.
>
> Heinrich makes the point that this code cannot be used in SPL. It is
> precisely because of that that we need an SPL version of the config.
> Otherwise it will be enabled everywhere. The fact that it currently
> works is due to CONFIG_IS_ENABLED() not caring whether the Kconfig
> options it is checking are present or not. That needs to change with
> split config.

OK, so this belongs in the split config series then. That today
CONFIG_IS_ENABLED(FOO) evaluates to false if we never define
SPL/TPL/VPL_FOO as a symbol is a feature, not a glitch, of the system.
It's used both in cases like you further explained around EFI_LOADER
where we do have some additions to core functionality (like printing
EFI paths in lib/vsprintf.c) that will never be needed in SPL, but
modify code that is included in SPL, so it cannot just use IS_ENABLED or
an ifdef as that would be true in SPL, and bloat the code, so we rely on
an always false test. It's also been used a time or two for the case of
"today no one has SPL_FOO, but in the future they may, and would want
this path to be taken". That is rarer, but I know I did that at least
once.

--
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]