[coreboot] libpayload memalign

[Jordan Crouse]

On 19/08/08 20:24 +0200, Stefan Reinauer wrote:
> Jordan Crouse wrote:
> > On 19/08/08 19:26 +0200, Stefan Reinauer wrote:
> >   
> >> -- 
> >> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
> >>       Tel.: +49 761 7668825 • Fax: +49 761 7664613
> >> Email: info at coresystems.de  • http://www.coresystems.de/
> >> Registergericht: Amtsgericht Freiburg • HRB 7656
> >> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
> >>
> >>     
> >
> >   
> >> Add memalign, get aligned memory.
> >>
> >> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
> >>     
> >
> > This is a terrible amount of complexity for a simple aligned memory
> > function.  I realize you are trying to fit within the 16k boundaries,
> > but come on -  addr = ((addr + align - 1) / align) * align) is really all
> > you need.  Yes, I know that ends up wasting memory.
> >   
> I remember from Patrick's explanation was that the memory should be
> freeable with the normal free().
> 
> So a bit of complexity is also in that.
> 
> Patrick can explain this better.
> 
> Sure, it can be done simpler and less efficient. But from previous
> discussions I got the impression that this is not necessarily what we want.
> 
> > So more importantly then this individual patch, it seems pretty clear
> > that we are getting ready to push the boundaries of the static 16k heap.
> > The time has come to replace it a dynamic engine.  The dynamic engine can
> > take more advantage of the system memory, and we won't care so much if we
> > end up losing 13 bytes with a 16 byte alignment.
> >
> > The questions now are - where should we put the heap?  What sort of
> > implementation should we go for?  Is the current mode scalable (probably
> > not)?  I probably favor a linked list implementation.  What restrictions
> > should we have on the size of the heap or the number of allocations?
> >   
> 
> With regard to the fact that quite some payloads might want to load an
> OS at an arbitrary address, limiting the available memory to something
> considerably less than the maximum amount of memory makes sense. Does it?
> 
> If we agree on that, the "dynamic" part would merely be to determine a
> good _heap and _eheap address during runtime.
> 
> I'm not convinced yet, that the current scheme needs to be changed at
> all. It's working quite nicely for us. But then again, if you're going
> to make things more dynamic, I am all for it.

If it was working nicely for us, then memalign() would have been at most
an extra line or two.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.