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