Hello Marek, On Sun, Aug 12, 2012 at 1:16 AM, Marek Vasut <ma...@denx.de> wrote: > > 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.
I doubt that on ARM for instance you can set off real mallocator that early without completely rewriting it. The idea of having one complex mallocator working in the same manner in board_init_f and board_init_r stages, being able to operate on all platforms using their nifty memory-management/model features and being seamless to users is really tempting. But do we need/want to introduce such deep rewrites? What would be the justification? I would say we should stick with the Wolfgang's opinion: Create small and efficient early_malloc for DM and prepare it for future extensions and possible reuses. >> 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 ... Yes, this is the main question: Should I hack malloc() function or does it make sense to have both early_malloc() and malloc() exposed to DM cores/drivers? The first is better from the point of view of drivers - when you ask for memory, you get it. But you have to check yourself whether you need to relocate your pointers or not, though we can provide "relocation chain" you can register your relocation routine into to facilitate it. The later makes sense because this makes it explicit that whenever you use early_malloc() you are responsible for relocating your data on your own (again, we can provide some facility for ir). There is a third path possible: We can provide early_malloc() and say wrapped_malloc() which can be the third function "give me memory, I do not care whether it is early or not". So drivers and/or DM can choose to use malloc routines working in early-only, late-only or both. Tomas -- Tomáš Hlaváček <tmshl...@gmail.com> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
