[U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf

[Lei Wen]

Hi Wolfgang,

On Sat, Feb 5, 2011 at 5:18 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Lei Wen,
>
> In message <1296788903-7604-1-git-send-email-leiwen at marvell.com> you wrote:
>> Original env buf directly locate at stack lead large stack footprint
>> when call those env functions. It is not good when the system memory
>> is critical or only want the uboot run at restrict range, that is not
>> to touch the memory of other place at its best.
>>
>> So now this patch move the env buf to the heap area, which reduce the
>> area uboot need to touch.
>
> In which way do you think this will save any memory?

This patch is not intend to save memory...

>
> Your switch from automatic variables to manually allocated ones has,
> in my opinion several disadvantages:
>
> 1) It increases the code size.
Yes, I agree.

>
> 2) It increases the probability of bugs like memory leaks etc.
>
> 3) Instead of using the stack, which gets allocated fully dynamically
>   and gets freed guaranteed completely when the function returns,
>   you now need at least the same space in the malloc arena - where
>   you have to allocate it statically, and where allocations of
>   buffers like that can easily lead to memory fragmentation,
>   increasing the memory footprint further.
>
> Did you do any specific measurements of memory footprint, or what
> makes you believe your code is preferrable?

One of our project need to confine the ddr usage of uboot in the smallest case,
not to pollute other area. So for us, the small stack is good one...

For now the uboot is relocated to the end of the dram, and malloc area is
almost a fix value, uboot would live happily in this area. But for env case,
it allocate a range which could be large, due to the CONFIG_ENV_SIZE
could be a big one, in the stack range. Because the stack is grown downwards,
so it takes more memory range than it is allocated in the malloc method.

Best regards,
Lei