From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Tue, 25 Sep 2012 10:37:08 +1000
Subject: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
In-Reply-To: <201209241619.50452.marex@denx.de>
References: <1346069529-27397-1-git-send-email-tmshlvck@gmail.com>
	<201209240111.57287.marex@denx.de>
	<CAEB7QLCgLJr4pEZDRooUrDjfikxyk-STE9n3XW_EQSP_j4qYrA@mail.gmail.com>
	<201209241619.50452.marex@denx.de>
Message-ID: <CALButCK8f7A5t5ARbokEpRBWtn=EdN0n111u6MXa7M+k4MD6zg@mail.gmail.com>
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

Hi Marek,

On Tue, Sep 25, 2012 at 12:19 AM, Marek Vasut <marex@denx.de> wrote:
> 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.