[U-Boot] [RFC][PATCH] Update malloc to dlmalloc version 2.8.4

[Mike Frysinger <vapier@gentoo.org>]

On Wednesday 08 July 2009 02:58:42 Peter Tyser wrote:
> Robin Getz wrote:
> > On Wed 8 Jul 2009 01:58, Mike Frysinger pondered:
> >> On Tuesday 07 July 2009 18:24:56 Kumar Gala wrote:
> >>> On Jul 7, 2009, at 3:25 PM, Scott Wood wrote:
> >>>> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>> On 15:02 Tue 07 Jul     , Scott Wood wrote:
> >>>>>> Kumar Gala wrote:
> >>>>>>> Those would help if the data structs had gotten bigger.  In this
> >>>>>>> case  the code itself is just larger.
> >>>>>>
> >>>>>> Perhaps we should look into using/writing a malloc implementation
> >>>>>> that takes a space/speed tradeoff more in line with U-boot's
> >>>>>> requirements (using a simple first-fit linear scan of free blocks,
> >>>>>> for example) -- and hopefully more readable than dlmalloc?
> >>>>>>
> >>>>>> I nominate those with the tightest space requirements to do
> >>>>>> this. :-)
> >>>>>
> >>>>> I agree it's sound a better plan
> >>>>> but I'll take a lot's of time
> >>>
> >>> Do we think there is some other project that we can acquire one from?
> >>
> >> there was another public domain malloc implementation Robin pointed me
> >> to recently, but i cant seem to remember/find it.
> >
> > It was bget
> >
> > http://www.fourmilab.ch/bget/
>
> The CFE bootloader has a pretty simple malloc implementation.  It looks
> relatively readable and is much smaller than dlmalloc:
>
> ptyser at petert cfe$ size cfe30/lib_malloc.o
>     text    data     bss     dec     hex filename
>     1128       4       0    1132     46c cfe30/lib_malloc.o
>
> http://www.broadcom.com/support/communications_processors/downloads.php
>
> Some other liberally licensed bootloaders such as PMON2000 might have
> some basic implementations too.

it's trivial to find smaller implementations.  i guess the problem we have is 
that we dont have any guidelines for what we want out of a malloc 
implementation.  i would bet that dlmalloc fairs better than these simple 
implementations wrt fragmentation, re-use, and freeing.  but if our typical u-
boot usage does little malloc/free, then this better behavior doesnt really 
matter to us.

does dlmalloc have any compile time knobs to help direct the functionality 
actually desired ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090708/7eec9f4b/attachment.pgp