Re: PATCH: Add memreserve to DTC

On Tue, Jul 12, 2005 at 10:02:16AM +0200, Segher Boessenkool wrote:

quoted

quoted

quoted

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