[PATCH v2 1/3] Image size checks: Remove HAS_BOARD_SIZE_LIMIT
Tom Rini
trini at konsulko.com
Thu Aug 7 22:11:42 CEST 2025
On Thu, Aug 07, 2025 at 09:41:34PM +0200, Marek Vasut wrote:
> On 8/7/25 6:21 PM, Tom Rini wrote:
> > On Thu, Aug 07, 2025 at 03:41:38PM +0200, Marek Vasut wrote:
> > > On 8/7/25 12:24 PM, Philip Oberfichtner wrote:
> > > > CONFIG_HAS_BOARD_SIZE_LIMIT is obsolete, if we interpret the value
> > > > "zero" as "unlimited".
> > >
> > > This sentence makes no sense. Is the variable not obsolete if its value is
> > > non-zero ?
> >
> > This is phrased oddly, yes. How about:
> > By making the code treat a size limit of 0 as unlimited we no longer
> > need to guard asking about having a size limit on the platform.
>
> 0 shouldn't mean unlimited, that is just fragile ...
That's a standard unix thing? ulimit -c 0 is unlimited.
> > > [...]
> > >
> > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > index c2aa88f59fb..36eed766d31 100644
> > > > --- a/lib/efi_loader/Kconfig
> > > > +++ b/lib/efi_loader/Kconfig
> > > > @@ -74,7 +74,7 @@ config EFI_SIGNATURE_SUPPORT
> > > > config EFI_DEBUG_SUPPORT
> > > > bool "EFI Debug Support"
> > > > - default y if !HAS_BOARD_SIZE_LIMIT
> > > > + default y if BOARD_SIZE_LIMIT = 0
> > > This looks wrong, no board size limit does not imply EFI anything.
> >
> > This is however preserving the existing functionality. Saying that no,
> > we shouldn't enable EFI debug support by default in any cases would be a
> > stand alone patch.
> ... fragile and confusing. HAS_BOARD_SIZE_LIMIT is at least clear about what
> it does.
I don't know how one is more or less clear than the other, sorry.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250807/c5d24e8f/attachment.sig>
More information about the U-Boot
mailing list