From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 07 Jul 2009 15:25:14 -0500 Subject: [U-Boot] [RFC][PATCH] Update malloc to dlmalloc version 2.8.4 In-Reply-To: <20090707202216.GJ30172@game.jcrosoft.org> References: <1246984027-8136-1-git-send-email-galak@kernel.crashing.org> <200907071434.33729.vapier@gentoo.org> <20090707191627.GE3979@email.mot.com> <720F17F7-4145-49F8-9554-5A381319446F@kernel.crashing.org> <4A53A9C1.2060309@freescale.com> <20090707202216.GJ30172@game.jcrosoft.org> Message-ID: <4A53AF2A.7040909@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 Right, for now we can use the existing malloc with -fno-strict-aliasing. -Scott