[PATCH 6/10] ppc64: Create a fake flat device tree on iSeries

[Milton Miller]

On Aug 10, 2005, at 10:14 PM, David Gibson wrote:

>
> On Wed, Aug 10, 2005 at 08:59:51AM -0500, Milton Miller wrote:
>>
>> On Aug 10, 2005, at 3:32 AM, David Gibson wrote:
>>
>>> On Wed, Aug 10, 2005 at 02:16:15AM -0500, Milton Miller wrote:
>>>> Putting the
>>>> device data at klimit would allow the checks for overflow to be
>>>> deferred until after its created (look for 2 nuls in string table
>>>> -- the size is propnum(""), and placing data at after the reserve
>>>> map and string table and either compare to total size or set
>>>> totalsize according to what is used).
>>>
>>

>> My other generator does this very thing.  The strings are allocated
>> statically.
>>
>> While discussing embedded with panto on #mklinux, another approach
>> is to say "here's the max", put the strings at the end, and allocate
>> new strings down moving the start as we add strings.
>
> An memmove() on every string insertion?  That's kinda horrible..

NO!   I agree, that would be.

I was saying 1 memmove on "oops we didn't alocate enough, allocate
a bigger area" and and optional one after everything else to say
"well, we allocated a 16k chunk and used 8 bytes, lets save a 3 pages".


By inserting strings by growing down towards the blob we just have
to update the start of the string table.

I just realized why that doesn't work --- the offset would keep 
changing.

... this still doesn't keep us from makeing an optimistic guess
how much string table and device tree we need an doing a memmove when
we were wrong.

>
>> Makes sense for
>> fw where there is a fixed allocation.  End of blob processing can
>> then memmove the string table and cut total size down.
>>
>> Even without the knowing the max size realloc could move strings down
>> if a space check is added before extending the dt blob.

milton