On Thu, Jul 25, 2024 at 07:59:52AM -0600, Simon Glass wrote: > Hi Sughosh, > > On Thu, 25 Jul 2024 at 06:54, Sughosh Ganu <sughosh.g...@linaro.org> wrote: > > > > On Thu, 25 Jul 2024 at 02:24, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Wed, Jul 24, 2024 at 11:31:48AM +0530, Sughosh Ganu wrote: > > > > > > > From: Simon Glass <s...@chromium.org> > > > > > > > > Use this new data structure in the utility function. > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org> > > > > --- > > > > lib/strto.c | 35 +++++++++++++++++++---------------- > > > > 1 file changed, 19 insertions(+), 16 deletions(-) > > > > > > This is rather big growth when we didn't already have realloc: > > > 05: lib: Convert str_to_list() to use alist > > > aarch64: (for 1/1 boards) all +1765.0 rodata +37.0 text +1728.0 > > > xilinx_versal_mini_emmc0: all +1765 rodata +37 text +1728 > > > u-boot: add: 7/0, grow: 1/0 bytes: 1728/0 (1728) > > > function old new > > > delta > > > realloc - 1120 > > > +1120 > > > alist_ensure_ptr - 140 > > > +140 > > > alist_expand_to - 136 > > > +136 > > > alist_init - 108 > > > +108 > > > alist_uninit_move_ptr - 76 > > > +76 > > > alist_add_ptr - 72 > > > +72 > > > alist_uninit - 48 > > > +48 > > > str_to_list 204 232 > > > +28 > > > > > > > I am working on an implementation of lmb maps using lists. The list > > nodes are then allocated with calloc, which I believe is included in > > most of the board images. We can then compare the size impact with the > > two implementations (alist vs list). Thanks. > > This is for use with EFI,
Am I missing some context? The LMB rework is because what we have today doesn't work all that well for what we need in a modern system (and with modern security concious eyes on the code) with EFI_LOADER=n. > which is very large, so I doubt it is worth > it. The alist code is simpler to work with and will be used in UPL and > likely some other areas. > > We could provide a variant which uses malloc()/free() instead of > realloc(), as I mentioned/ The impact then would be very small. Switching to malloc/free instead might be fine as well, yes. Aside from the realloc growth most platforms are at a minor size shrink. If we address realloc then we get something more functional and smaller. This should make everyone happy. -- Tom
signature.asc
Description: PGP signature
