From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Mon, 24 Sep 2012 16:19:50 +0200
Subject: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
In-Reply-To: <CAEB7QLCgLJr4pEZDRooUrDjfikxyk-STE9n3XW_EQSP_j4qYrA@mail.gmail.com>
References: <1346069529-27397-1-git-send-email-tmshlvck@gmail.com>
	<201209240111.57287.marex@denx.de>
	<CAEB7QLCgLJr4pEZDRooUrDjfikxyk-STE9n3XW_EQSP_j4qYrA@mail.gmail.com>
Message-ID: <201209241619.50452.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Tomas Hlavacek,

[...]

> >> +static inline void *dmrealloc(void *oldmem, size_t bytes)
> >> +{
> >> +#ifdef CONFIG_SYS_EARLY_MALLOC
> >> +     if (early_malloc_active())
> >> +             return NULL;
> > 
> > I wonder how should this be implemented ... maybe early_malloc + standard
> > memcpy()
> 
> How do you want me to fix all the pointers to the memcpyied part of
> heap then? I think this will not work unless I make some reservations
> for eventual growth for each and every early_mallocated area. And I
> think this is not good idea at all for early_malloc.

What exactly would you need to fix ? It's only a matter of allocating new block, 
copying the existing data there and returning the pointer to the new block, no?

> I think there are two straight-forward possibilities: a) keep the
> empty implementation of dmrealloc() in early stage and avoid using it
> in code which might run in early stage, but retain the dm* version of
> the symbol. b) remove the dmrealloc() entirely which may have certain
> negative consequences, because it might be tempting to mix dmmalloc()
> and (non-dm*) realloc() calls which is obviously wrong.
> 
> Tomas

Best regards,
Marek Vasut