From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Tue, 25 Sep 2012 19:09:15 +1000
Subject: [U-Boot] [PATCH v8] [RFC] early_malloc for DM added.
In-Reply-To: <CAEB7QLCaFBAWQNVaRYQoSkcgzfLwj765fAh2QG4tMnRihDy_Mw@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>
	<201209241619.50452.marex@denx.de>
	<CALButCK8f7A5t5ARbokEpRBWtn=EdN0n111u6MXa7M+k4MD6zg@mail.gmail.com>
	<CAEB7QLCaFBAWQNVaRYQoSkcgzfLwj765fAh2QG4tMnRihDy_Mw@mail.gmail.com>
Message-ID: <CALButCKTSLRAq-A=8R3FPSEyoa2RWYas7XFP7rw5PBqg0xq+tw@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 Thomas,

On Sep 25, 2012 6:43 PM, "Tomas Hlavacek" <tmshlvck@gmail.com> wrote:
>
> Hello Graeme!
>
> On Tue, Sep 25, 2012 at 2:37 AM, Graeme Russ <graeme.russ@gmail.com>
wrote:
> > Hi Marek,
>
> [...]
>
> > The last two are NOPs for early heap as we have no way to track free'd
blocks
> >
> > Keep in mind that 'real' realloc() has access to information providing
> > the size of the source block of allocated memory, so it can do a
> > memcpy using (at least a good guess of) the size of the source block.
> > In the early heap case, we do not have that data, so we would need to
> > memcpy the entire size of the destination block - this will likely
> > bring in garbage (no problem as we there is nothing in the spec to
> > forbid that) and _might_ have some interesting boundary conditions
> > (what happens if we memcpy past the end of an early heap block into
> > ga-ga land?)
>
> I was thinking about such simple implementation:
>
> static inline void *dmrealloc(void *oldaddr, size_t bytes)
> {
> #ifdef CONFIG_SYS_EARLY_MALLOC
>         char *addr;
>         if (early_malloc_active()) {
>                 addr = dmalloc(bytes);
>                 memcpy(addr, oldaddr, bytes);
>                 return addr;
>         }
> #endif /* CONFIG_SYS_EARLY_MALLOC */
>         return dmrealloc(oldmem, bytes);
> }
>
> But then the fun comes: I can not distinguish the case when you have
> 100 B char *x allocated and you called dmrealloc(x, 99). And I can hit
> some boundaries as
>
> But yes, we can have such a stupid implementation. Or I can use
> early_malloc frame header which would contain magic (to detect wrong
> dmrealloc calls on arbitrary pointer) and size, so I would be able to
> do free and realloc. Then I would need new free-space enumeration
> mechanism to reuse free space (let's say that I can create a linked
> list of free headers), so the frame header is going to be 12 B total.
> Or we can have no implementation of dmrealloc at all.

We should implement each of malloc(), free(), calloc(), and realloc().

Don't worry about reclaiming and reusing space with a proper free()
implementation. Remember, all memory allocated on the early heap must be
relocated anyway.

Maybe if you add a size_t value immediately before the allocated space
which stores the block size. So:

size_t *bytes_ptr = ptr;
bytes_ptr--;
size_t bytes = *bytes_ptr;

gives you the block size

Regards,

Graeme