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

[Marek Vasut]

On 8/11/25 10:50 AM, Philip Oberfichtner wrote:
> On Thu, Aug 07, 2025 at 05:24:21PM -0600, Tom Rini wrote:
>> 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.
> 
> The idea of treating a size limit of zero as unlimited has been common
> practice in mainline U-Boot since 2019, where CONFIG_SPL_SIZE_LIMIT has
> been introduced. The same logic has later been applied to TPL and VPL
> size limits.

That still does not make it the correct approach.

> If we want to consistently stick to the HAS_*_SIZE_LIMIT approach, we'd
> have to introduce four extra Kconfig options alongside
> HAS_BOARD_SIZE_LIMIT:
> 
> 	CONFIG_HAS_UBOOT_WITH_SPL_SIZE_LIMIT

What does this one do ?

> 	CONFIG_HAS_SPL_SIZE_LIMIT
> 	CONFIG_HAS_TPL_SIZE_LIMIT
> 	CONFIG_HAS_VPL_SIZE_LIMIT

This is fine by me.

> Furthermore, the extra lines of code in the toplevel Makefile, which
> could otherwise be removed:
> 
> 	ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
> 	BOARD_SIZE_CHECK= @ $(call size_check,$@,$(CONFIG_BOARD_SIZE_LIMIT))
> 	else
> 	BOARD_SIZE_CHECK =
> 	endif
> 
> 	ifneq ($(CONFIG_HAS_UBOOT_WITH_SPL_SIZE_LIMIT),0x0)
> 	UBOOT_WITH_SPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_UBOOT_WITH_SPL_SIZE_LIMIT)
> 	else
> 	UBOOT_WITH_SPL_SIZE_CHECK =
> 	endif
> 
> 	ifneq ($(CONFIG_SPL_SIZE_LIMIT),0x0)
> 	SPL_SIZE_CHECK = @$(call size_check,$@,$$(tools/spl_size_limit))
> 	else
> 	SPL_SIZE_CHECK =
> 	endif
> 
> 	ifneq ($(CONFIG_TPL_SIZE_LIMIT),0x0)
> 	TPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_TPL_SIZE_LIMIT))
> 	else
> 	TPL_SIZE_CHECK =
> 	endif
> 
> 	ifneq ($(CONFIG_VPL_SIZE_LIMIT),0x0)
> 	VPL_SIZE_CHECK = @$(call size_check,$@,$(CONFIG_VPL_SIZE_LIMIT))
> 	else
> 	VPL_SIZE_CHECK =
> 	endif

This code is already in the U-Boot Makefile .

Maybe tools/spl_size_limit.c could be somehow extended to deduplicate 
the above ?

> Is it really worth adding this much of extra code?
Yes, because 0 does not mean unlimited .