From: Marek Vasut <[email protected]> Sent: Wednesday, October 23, 2024 4:05 PM > 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.
I will make a V2 with this approach, but unfortunately I can't work on it next week. So the week after I will send V2. Regards Christoph
