[U-Boot] [PATCH v8] [RFC] early_malloc for DM added.

[Tomas Hlavacek <tmshlvck@gmail.com>]

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.

Tomas