Dear Tomas Hlavacek,
Hello Marek,
On Sat, Jul 28, 2012 at 10:36 PM, Marek Vasut marex@denx.de wrote:
I think we should still mark early patches as RFC.
Sure...
+#include <earlymalloc.h>
Do we need early_malloc.h at all? malloc.h won't cut it?
My intention was to keep the early_malloc in separate instance from real malloc.
early_malloc.c is probably fine ... once you manage to properly wrap the calls to early_malloc()/dlmalloc() into malloc() and switch based on the GD flags. It's just the header file that I consider redundant.
Although this is proof-of-concept / RFC for early_malloc, it does not contain adaptation layer for switching malloc/early_malloc, because it seriously break things.
Why/how?
I wanted comments on the basic idea first.
- early_malloc_init();
So this basically flips a bit, do it the other way and you don't need it.
Well yes. I was told to support more stages of early_mallocator deactivation during DM core relocation.
Ok, add more flags maybe? Can you elaborate on the reason?
So this is why I have plenty of flags (currently using one).
Still, can you not wrap it into GD flags ?
Now I know at least about two stages and three states. Actually intended lifecycle of the early_malloc is:
- init:
What's "init" ... you mean board_init_f() ?
malloc() calls are switched to early_malloc()
Ok, but you must wrap this into malloc() call
other calls (=free(), realloc()...) are switched to dummy.
realloc() can work too, why not ? So can calloc() etc.
- relocation done
board_init_r() ?
real malloc initialized, before core relocation: malloc() switched to dlmalloc other calls to dummy (this is special mode for core relocation, which prevents calling dlmaloc free() on space allocated by early_malloc().
I see ... ok, se please check if the GD flags can't be used, I think they can.
- Full switch to dlmalloc.
Sure we can make it simpler, if it is OK with prospective core relocation function.
No, we want this wrapped into malloc() call, so the drivers can be inited indifferent of time.
Sure. My intention was not to hack current malloc but rather create adaptation layer. Maybe not a good idea... Anyway I can put simple switches like
if(!(gd->flags & GD_FLG_RELOC)) return early_malloc();
directly into malloc() functions.
You can actually switch the mallocator so the functions exported by it are prefixed with dl ... and then just create some stuff that's called malloc() free() etc. and does the switching.
+typedef struct early_malloc_spc {
char flags;short size;char heap[EARLY_HEAP_SIZE];+} em_spc_t;
Drop the typedef please.
Actually I don't follow what is the problem here with the typedef?
http://lwn.net/Articles/2241/ ... but I'd like to gain opinions from other people on this one.
diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c index c88f5d4..6e39826 100644 --- a/lib/asm-offsets.c +++ b/lib/asm-offsets.c @@ -23,7 +23,7 @@ int main(void)
{
/* Round up to make sure size gives nice stack alignment */ DEFINE(GENERATED_GBL_DATA_SIZE,
(sizeof(struct global_data) + 15) & ~15);
(sizeof(struct global_data_extended) + 15) & ~15);And if you adjusted the global data to be the "container of both, you won't need this here either.
Sure. My intention was to keep early_malloc heap in separate structure
Of course. My point was to do it the other way. But looking at it one more time, this seems correct.
(containing the GD structure) in order not to relocate it but rather relocate cores by ourselves, which was our plan. It would be simpler to have it in the end of standard GD structure, because we can drop multi-stage early_malloc turn-off and perhaps we are not going to need to do relocation of DM structures by hand.
Tomas
-- Tomáš Hlaváček tmshlvck@gmail.com
Best regards, Marek Vasut