On 10/23/24 3:20 PM, Christoph Niedermaier wrote:
From: Marek Vasut <[email protected]>
Sent: Wednesday, October 23, 2024 2:41 PM
On 10/23/24 2:18 PM, Christoph Niedermaier wrote:
[...]
You do not, the following automatically reserves space on stack when
called and frees it up upon function return:
function foo() {
u8 array[12];
...
stuff(array);
...
}
Sorry, I expressed myself incorrectly here. Of course I meant that
I don't want to reserve memory on the stack for the EEPROM ID page
in the board_init() function.
Why ?
It's about structuring the software. I want to isolate the function which
is responsible for evaluate the EEPROM from the caller function. I wanted
to avoid entangling the two. This means that I, as the caller of the function,
do not have to worry about the internal structure of the EEPROM ID page.
You are only passing in a block of unstructured memory allocated on
stack, u8 block[64].
I want to handle
size and caching in the function dh_get_value_from_eeprom_id_page(). So I don't
want to deal with size and structure in the function board_init(). For me, the
use
of a static variable is OK, but you don't like it. Do you know how I can do this
without assigning a static variable, but not allocate the memory somewhere in a
caller function?
Even the static variable space is allocated somewhere, either in .bss or
.data section, except with static variable(s) the memory persists
throughout the lifetime of U-Boot because their content has to be
retained even when the function using their content returns.
With variable(s) allocated on stack (which is majority of variable), the
memory allocation happens on entry to the function and the memory is
automatically freed on exit from the function.
It is perfectly fine to call some wrapper superfunction from
board_init() which holds the array on stack and calls all the EEPROM
parser/handler functions:
eeprom_superwrapper() {
u8 eeprom[64];
...
eeprom_do_stuff1(eeprom);
eeprom_do_stuff2(eeprom);
...
}
board_init() {
...
eeprom_superwrapper();
...
}
That's not what I'm looking for. Do you have another solution?
No. I do not understand what is the problem with allocating 64 Bytes on
stack ?
There is no problem with the reservation of the EEPROM buffer on the
stack. I wanted to isolate the evaluation function from the caller
function, so that I have no dependencies on the caller. Since there
seems to be no better solution, I will add the variable to the
board_init() function in V2.
There seem to be multiple functions using the same data, so you have to
pass pointer to those data around.
