PATCH: Add memreserve to DTC

David Gibson david at
Thu Jul 14 11:02:46 EST 2005

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 at	| solution which is simple, neat and
				| wrong.

More information about the Linuxppc-dev mailing list