[U-Boot] [PATCH 0/8] Clean up CONFIG_SYS_{CBSIZE, PBSIZE, MAXARGS, BARGSIZE} definitions

Dr. Philipp Tomsich philipp.tomsich at theobroma-systems.com
Fri Aug 25 11:31:27 UTC 2017

> On 24 Aug 2017, at 21:13, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:
> Hello,
> On Thu, 24 Aug 2017 20:53:35 +0200, Wolfgang Denk wrote:
>>> I believe this patch series is a step in that direction. With this
>>> patch series applied, we can now clearly identify which boards have
>>> custom values for CONFIG_SYS_{CBSIZE, PBSIZE, MAXARGS, BARGSIZE}, and
>>> therefore more easily move these from the .h files to defconfig files.  
>> So you think moving this to Kconfig would be a second step?  Ok,
>> fine with me.
> Yes, this would be a second step. The current patch series eliminates
> the situations where the .h files use the default values, or values
> that are close enough to the default values for the default value to
> remain reasonable.

Moving these to Kconfig would achieve the same, as boards that do
not override the defaults (or override the defaults with the same value)
would not have an entry added to their defconfig.

Furthermore, if there’s an override for an entire architecture (as I has
seen with the SPL_LDSCRIPT conversion), once can always have a
default value added to that architecture’s Kconfig.

In other words: I don’t see any value in doing this as a two-step process
as this will just trigger two rounds of reviews and integration testing.


> Of course, the patches should be reviewed, and the decision taken by
> them potentially discussed.
>>> The choice for such values is totally independent from the HW, but
>>> rather tied to the specific use of a given board. For the same board,  
>> No, it is not. Buffer sizes eat on RAM, and there are environments
>> (like today in SPL) where this may be a precious resource.
> Right, true.
>>> most people will find the default value to be OK, some people will need
>>> a larger number of command arguments or a bigger Linux kernel command
>>> line.
>>> Let me know what your preference is.  
>> I think it makes a lot of sense to keep such configuration parameters
>> changable, but we hould not stop half way but rather move this to
>> Kconfig so it's easy to use a default setting, and only boards with
>> special needs have to adjust this in their defconfig files.
> OK. So let's review this first patch series. Once we agree on it and it
> gets merged, I can work on the second step of moving those
> configuration options to Kconfig.
> Thanks for the very useful feedback!
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

More information about the U-Boot mailing list