[PATCH v2 1/3] Image size checks: Remove HAS_BOARD_SIZE_LIMIT

[Tom Rini]

On Fri, Aug 08, 2025 at 01:15:45AM +0200, Marek Vasut wrote:
> On 8/7/25 10:11 PM, Tom Rini wrote:
> > 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.
> 
> This is a really bad argument, because then the counter-argument is, that
> size = 0 is also a valid size and it shouldn't be conflated with SIZE_LIMIT
> validity.
> 
> My take on this is, don't conflate size-limit "enabled/disabled" with
> size-limit "value" , these are two separate config options. Mixing them is
> not helping.

I still think it's fine, but it's not worth arguing further over, and we
can just make sure to gate all of the symbols rather than 0-is-disabled.

-- 
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/6a34bdd4/attachment.sig>