Re: PATCH: Add memreserve to DTC

[David Gibson <david@gibson.dropbear.id.au>]

On Tue, Jul 12, 2005 at 10:02:16AM +0200, Segher Boessenkool wrote:
> >>> and forcing the user to
> >>>split up these 64-bit quantities into cells is kind of silly.
> >>
> >>Hey, I didn't set that up! :-)  There wasn't an existing
> >>clean way to state 64 bit values, and an arbitrary list of
> >>them.  So I uh, leveraged the existing cell_t support!
> >
> >Cells make sense for the actual OF-like data, becayse they're an OF
> >concept.  For memreserve, which is purely Linux specific, they don't/
> 
> No.  This is _not_ what is called a cell.  "Cell" is a Forth concept.
> A cell can be any size.  Open Firmware puts the extra restriction on it
> to be _at least_ 32 bits.
> 
> The thing you are referring to is what is called in OF
> 
> 	"32-bit integer property encoding format".
> 
> It is defined to always be 32-bit, and not the cell size of the 
> firmware,
> so that you can use a 64-bit firmware with a 32-bit OS, and vice versa
> (of course there could be different reasons why this isn't practical, 
> but
> that's not the point).
> 
> In OF words, this format is normally abbreviated as "int".

My mistake, I misunderstood the terminology.  But the basic point is
that lots of things in the kernel already assume a cell is 32-bits, so
it would be silly to try and change that here.  This is not true for
the memreserve values.

> Btw -- beware of the fact that such an "int" does _not_ have any
> alignment restrictions -- so you better read it byte by byte...

Erm.. in what context.  dtc never reads ints from the blob format as
ints - properties are just byte strings to it.  At present you can't
mix cell input format with other sorts, which means the ints must, in
fact, be aligned, since properties are.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson