[U-Boot] Early malloc() summary

[Graeme Russ]

Hi Marek,

On Tue, Aug 14, 2012 at 10:37 PM, Marek Vasut <marex at denx.de> wrote:
> Dear Tomas Hlavacek,
>
>> Hello Marek,
>>
>> On Sun, Aug 12, 2012 at 1:16 AM, Marek Vasut <marex at denx.de> wrote:
>> > So ... we should aim for firing up the real mallocator as soon as
>> > possible and maybe implement discontigmem (sparsemem) into it, so we
>> > don't have to bother with relocating pointers maybe?
>> >
>> > The only problem I see is platforms where the memory disappears.
>>
>> I doubt that on ARM for instance you can set off real mallocator that
>> early without completely rewriting it.
>
> Esp. on ARM, I won't see much of a problem. You usually have some small SRAM
> where such allocator could run.
>
>> The idea of having one complex
>> mallocator working in the same manner in board_init_f and board_init_r
>> stages, being able to operate on all platforms using their nifty
>> memory-management/model features
>
> Do you need them? You usually need only a piece of RW memory.
>
>> and being seamless to users is really
>> tempting. But do we need/want to introduce such deep rewrites?
>
> Deep rewrites? You'd only need to implement sparsemem into it, which might be
> list of RW memory areas instead of one memory area.
>

OK, stop right there (please) - This gets into a highly architecturally
specific implementations of malloc. Let's not go there OK :)

>> What
>> would be the justification? I would say we should stick with the
>> Wolfgang's opinion: Create small and efficient early_malloc for DM and
>> prepare it for future extensions and possible reuses.
>
> dm_malloc you mean? I'm not happy about it, maybe Graeme can pour in some crazy
> juice in our direction again?

I don't like the idea of dm_malloc() either, but it may be the only way to
get this past Wolfgang in the initial pass...

>> >> Switching the focus back to DM, I really would like to ask to delay
>> >> alls uch activities until DM has been done (or at least has stabilized
>> >> so far that we can affort the luxury of thinking about the next
>> >> version with fancy extensions).
>> >
>> > We still need to handle the pre-reloc drivers somehow, you know ... but I
>> > still believe we can pull the DM internals in three people and leave
>> > Thomas to do proper malloc stuff ...
>>
>> Yes, this is the main question: Should I hack malloc() function or
>> does it make sense to have both early_malloc() and malloc() exposed to
>> DM cores/drivers?
>
> This is indeed the main question -- ideas ?
>
>> The first is better from the point of view of drivers - when you ask
>> for memory, you get it. But you have to check yourself whether you
>> need to relocate your pointers or not, though we can provide
>> "relocation chain" you can register your relocation routine into to
>> facilitate it. The later makes sense because this makes it explicit
>> that whenever you use early_malloc() you are responsible for
>> relocating your data on your own (again, we can provide some facility
>> for ir).

And there is the crux of it. Two failure scenarios:

 1) Write a driver which uses malloc() and fail to implement a relocation
    helper - Driver blows up after relocation

 2) Write a driver using malloc() which you never thought to use prior to
    relocation and it blows up because someone used it pre-relocation or
    in SPL and didn't convert it to use early_malloc()

Neither can be picked up by at build time...

>> There is a third path possible: We can provide early_malloc() and say
>> wrapped_malloc() which can be the third function "give me memory, I do
>> not care whether it is early or not". So drivers and/or DM can choose
>> to use malloc routines working in early-only, late-only or both.

Third path is dm_malloc() - Although ugly, it has a few nicities...

 1) It wraps malloc() and early_malloc() around a gd->flags & GD_FLG_RELOC
    test
 2) We can pass a pointer to a driver_core struct (or whatever struct it
    is that holds the 'reloc' helper function pointer). We can't pick up
    misuse at compile time, but dm_malloc() can print a meaningful message
    if it is called pre-relocation with no relocation function. (We should
    add a flag to indicate that no relocation helper is required which may
    be the case for very simple drivers)
 3) We can see right away when driver developers forget to use it
 4) It will (hopefully) get past Wolfgang
 5) It can be implemented 'right now'
 6) We can always come back later and replace it since the usage will be
    consistent

So my vote would be for:

void *early_malloc(size_t bytes)
{
   ...blah...
}

void *dm_malloc(struct driver_core *drv, size_t bytes)
{
  if (gd->flags & GD_FLG_RELOC) {
    return malloc(bytes);
  } else {
    if (!drv->reloc && !(drv->flags & NO_RELOC_FUNC))
      puts("ARRRRRGGGGGG - Early malloc with no reloc function!!!!");
    return early_malloc(bytes);
  }
}

Let's leave it at that for the time being - my other thought of registering
ealry_malloc relocation helpers can wait until someone other than DM needs
to use early_malloc(). Until then, DM can deal with managing the calls to
the relocation functions.

Hows that sound?

Regards,

Graeme