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