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

[David Gibson]

On Sat, Aug 13, 2005 at 03:44:50PM -0500, Milton Miller wrote:
> 
> 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.

That's what I was getting at.  Sorry, I should have been clearer.

paulus did point out that we could do it this way if we allowed
negative string offsets.  But that gets potentially ghastly if we ever
needed to copy the device blob around as a unit.

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

Hrm, I guess.  I don't really seeing the advantage over just growing
upwards, though.  However, from talking with Michael the other day, I
think he came up with a reasonable way of statically allocating the
strings table which is probably a better option.

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

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/people/dgibson