[U-Boot] Early malloc() summary

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCL9btmPEW3Uiv9=tU4Yk7fdTUruzpCcVqMLynpzWv6Pug at mail.gmail.com> you wrote:
> 
> While the need for early malloc() came about from the driver model and
> the desire to make drivers usable before relocation, I think we can all
> agree that its scope may well not be limited to use by drivers. A few
> examples I can think of the top of my head include:

I agree with all this,  but can we please stop this discussion here
and now?

The DM project is big and complicated enough, and I would really like
that they can come up with a straightforward, simple and robust
design.

Adding additional requirements to DM parts here and there will make
this even more complex, and delay design and implementation.

Given that the project team is running under some resource
constrictions (like we all do) we should try to help to get this
implemented as quickly as possible, and not add more and more
requirements that actually have nothing to do with DM.

I suggest we discuss such an extension separately, and ideally after
the DM code has been merged mainline.


> So we all know the intent:
>  - have the ability to allocate memory prior to relocation

Actually I see things different.

With the advent of SPL the strict barrier before/after relocation has
started to crumble.  Already now we have systems which set up a "real"
malloc arena and stack in RAM in the SPL, so they can use features
(like file system support) at a stage that in our "pre/after" type of
thinking would never allow it.

Initally I was not happy about this, and anly accepted it grudgingly,
but the longer I think about it I tend to believe that we really
should allow users such flexibility if their hardware allows it.
Hardware configurations have become so manifold that we should allow
to make maximum use of available features.

So we not only talk about malloc() before "relocation", but actually
runnign arbitrary code.

> And we all know the problems:
>  1. Preserving allocation references accross relocation
>  2. Any given driver may need to use early malloc() on some boards but not
>     on others

Again, I think we will have separate interfaces for malloc(0 and
early_malloc().  Code that cannot be sure of it's runtime environment
(like drivers) will have to provide proper provisions for a mode
switch.  All other code should either "just work" (if standard
malloc() is available under this name, then it is supposed to work),
or break at build time (because f unresolved references to the
malloc/calloc/free names).

> My thought: Keep it simple for now. Worry about optimising it to death
> later.


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).

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If only God would give me some clear sign! Like making a large  depo-
sit in my name at a Swiss Bank.                         - Woody Allen