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

[David Gibson]

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:
> >>
> >>5) If you are going to statically allocate this for iSeries (as
> >>opossed to say a klimit bump), then the only thing in dynamic is
> >>setting the boot cpuid.  May as well use a static initializer.
> >>
> >>Today this would add over 2 pages of bss for a "combined" kernel.
> >
> >I think you'll find there are patches coming making more stuff
> >dynamic.  Virtual devices, in particular.
> 
> Sorry, wasn't trying to imply making the whole tree static, just
> the header.   But I would rather see it allocated at klimit ...
> 
> 
> >
> >>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).
> >
> >Hrm.. actually.. this may be too irritatingly inflexible, but since
> >the iseries device tree is pretty limited in what it contains, it
> >would potentially be possible to statically initialize a string table
> >containing every property name iSeries might ever use.  In fact, doing
> >it that way you could generate the skeleton of the device tree with
> >dtc (asm output mode), leaving some space in the structure section,
> >then add in the dynamic structure at runtime.  (I'd need to add
> >something to dtc to allow you to force a string into the string
> >section even if it's not used in the tree, of course, but that should
> >be easy)
> 
> 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..

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

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