[U-Boot] early_malloc outline

[Graeme Russ <graeme.russ@gmail.com>]

Hi Thomas,

On 08/09/2012 06:58 PM, Tomas Hlavacek wrote:
> Hi Graeme,
> 
> On Thu, Aug 9, 2012 at 1:33 AM, Graeme Russ <graeme.russ@gmail.com> wrote:
> 
>>
>> OK, this got me to thinking about the 'relocation' function in the driver
>> structure and how we can make the early heap more generic. My thoughts tie
>> into the DM tree structure being discussed in another thread...
>>
> [snip]
>>
>> Then in relocate_code() we call relocate_early_malloc() which simply walks
>> the relocation function list and calls each one. Each function is
>> responsible for allocating new memory form the final heap and copying the
>> data from the early heap to the newly allocated memory
>>
>> This way, anyone (not just drivers) can take advantage of the early heap.
>> And if a user of early heap does not care about the data being available
>> post relocation, they just don't bother implementing and registering a
>> relocation function.
> 
> I am wandering how could it be implemented on certain platforms (ARM

Forget about platform specifics - Not.....Your.....Problem ;)

> for instance) without wasting memory for blind copy of all data (even
> data that the user does not want to relocate afterwards) or without

Easy - don't blind copy. Each (and every) user of early malloc needs their
own relocation routine. The user of the early heap gets to decide what gets
copied to final heap. Let's look at a couple of scenarios:

a) Pre-console buffer gets allocated pre-relocation. The contents get
   dumped as soon as console is available (usually before relocation) so
   the pre-console buffer does not need to be relocated to final heap

b) Something (who know what) builds a tree during platform init prior to
   relocation. After the tree has been built, no elements will be added or
   deleted. So during relocation, instead of a tree, a simple array is
   allocated and the elements copied into it in order (so a simple binary
   search can be conducted late)

> initializing real_malloc() and doing relocation when caches are still
> disabled. Maybe it is a technical detail now but it seems to me that
> some trade off in this situation might be needed.

Bingo! - Don't sweat the details. Provide a well-structured API and if
there are performance gains to be made later, they can be made.

Remember, the whole point of implementing the new driver model is to bring
in a consistent API. To support that, you made need sub-features with their
own APIs. In a lot of respects, it matters less if the API is imperfect if
it is wholly consistent

Regards,

Graeme