All of lore.kernel.org
 help / color / mirror / Atom feed
* Alignment of mixed-data type items in properties
@ 2010-11-09  1:07 David VomLehn
       [not found] ` <20101109010709.GA10639-ZEW99E7oL/EiWxQNNj96ibh/4TqKg8J2XqFh9Ls21Oc@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: David VomLehn @ 2010-11-09  1:07 UTC (permalink / raw)
  To: Device Tree Mailing List

I have a property that seems most simply expressed as:

	prop = "abc",<0x12345678 0x87654321>;

It looks like the u32 values are not aligned on four-byte boundaries. Given
the effort elsewhere in the device tree to make things aligned, this was
a bit of a surprise. It's easy enough to handle; I'm just wondering whether
this was the intent.
-- 
David VL

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Alignment of mixed-data type items in properties
       [not found] ` <20101109010709.GA10639-ZEW99E7oL/EiWxQNNj96ibh/4TqKg8J2XqFh9Ls21Oc@public.gmane.org>
@ 2010-11-09  1:28   ` David Gibson
  2010-11-09  5:09     ` Mitch Bradley
  0 siblings, 1 reply; 3+ messages in thread
From: David Gibson @ 2010-11-09  1:28 UTC (permalink / raw)
  To: David VomLehn; +Cc: Device Tree Mailing List

On Mon, Nov 08, 2010 at 05:07:09PM -0800, David VomLehn wrote:
> I have a property that seems most simply expressed as:
> 
> 	prop = "abc",<0x12345678 0x87654321>;
> 
> It looks like the u32 values are not aligned on four-byte
> boundaries.

Well, actually, in this case it will be 4-byte aligned, because "abc"
is 4 bytes in length ('a', 'b', 'c', '\0').  But in general, that's
right, u32 values will not be aligned if they follow something of
unaligned length.

> Given the effort elsewhere in the device tree to make
> things aligned,

That's in the tree structure, not the contents.  The property values
are just bytestrings as far as the dtb format is concerned.

> this was a bit of a surprise. It's easy enough to
> handle; I'm just wondering whether this was the intent.

Yes, it's the intent.  Early on we did align u32 values, but we
realised that was a bad idea.  It doesn't really correspond to how OF
did encode property values, and it gets confusing in more complex
examples (including some possible future syntax).  Consider for
example
	&label, <0x1234>
We wouldn't know how much alignment to insert until the label is
expanded.  It gets much worse if we support expressions in future.

-- 
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/~dgibson

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Alignment of mixed-data type items in properties
  2010-11-09  1:28   ` David Gibson
@ 2010-11-09  5:09     ` Mitch Bradley
  0 siblings, 0 replies; 3+ messages in thread
From: Mitch Bradley @ 2010-11-09  5:09 UTC (permalink / raw)
  To: David Gibson; +Cc: Device Tree Mailing List

The reason for not aligning in Open Firmware
property values because I got tired of having
to fix structures that needed different padding
when moving to different systems.  I just decided
to dispense with alignment, constructing property
values with serialization functions and reading
them with deserialization functions.

People often get away with structure-based property
access techniques, but the "official model" is based
on a byte stream of concatenated elements with no
internal alignment.

Mitch Bradley

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-11-09  5:09 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-09  1:07 Alignment of mixed-data type items in properties David VomLehn
     [not found] ` <20101109010709.GA10639-ZEW99E7oL/EiWxQNNj96ibh/4TqKg8J2XqFh9Ls21Oc@public.gmane.org>
2010-11-09  1:28   ` David Gibson
2010-11-09  5:09     ` Mitch Bradley

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.