[U-Boot] Early malloc() summary

[Marek Vasut]

Dear 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?

Why should we? We can still run the DM in three people and leave the malloc 
stuff offloaded to Thomas, as he is gaining good knowledge of this stuff.

Besides, the malloc goo is pretty separate part.

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

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.

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

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

> Thanks.
> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Marek Vasut