[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <643bfc24-8cc1-4f70-85e2-f6829c8e03db@zytor.com>
Date: Mon, 26 Jan 2026 14:20:44 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Simon Glass <sjg@...omium.org>
Cc: ubizjak@...il.com, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
bp@...en8.de, dave.hansen@...ux.intel.com, kas@...nel.org,
kees@...nel.org, linux-coco@...ts.linux.dev, mingo@...hat.com,
nathan@...nel.org, peterz@...radead.org, pmladek@...e.com,
rick.p.edgecombe@...el.com, tglx@...nel.org, x86@...nel.org
Subject: Re: [PATCH v1 08/14] x86: make CONFIG_EFI_STUB unconditional
On 2026-01-26 13:19, Simon Glass wrote:
>>
>> Including the EFI stub doesn't mean using EFI to boot is required.
>
> Yes, understood, but it adds bloat. More importantly it will lead to
> people assuming that the stub is always used and thus unwittingly blur
> the boundary between the stub and the kernel itself.
>
> What is the actual need for this?
>
I would argue that the opposite is more likely: someone inadvertently builds a
kernel without the stub, the bootloader goes down a legacy support path and
things seems to work... except for some platform subtleties.
The bloat is there, but it is small and is only in the on-disk kernel image;
it is zero at runtime.
As such, I don't think this option is a particularly good idea anymore. If
necessary, it could be hidden behind an EXPERT option, but I first wanted to
see who if anyone actually cares in a meaningful way to maintain this option.
Every option, after all, adds maintenance burden.
Note that the BIOS stub is unconditionally compiled and included, and that has
not been an issue.
-hpa
Powered by blists - more mailing lists