[coreboot] libpayload memalign

[Stefan Reinauer]

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.

Stefan

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