RFC: Host-endian device tree format

[Dave Martin]

On Wed, Jan 19, 2011 at 11:47 PM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Wed, Jan 19, 2011 at 04:09:39PM +0000, Dave Martin wrote:
>> On Wed, Jan 19, 2011 at 3:52 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> > On Wed, Jan 19, 2011 at 8:41 AM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> >> On Wed, 19 Jan 2011, Dave Martin wrote:
>> >>> On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> >>> > The dtb isn't so much bigendian as it is network byte order.
>> >>>
>> >>> (For me, "network byte order" is a euphemism ... <insert
>> >>> unconstructive rant here>)
>> >>
>> >> I concur.
>> >
>> > meh. it's all about conventions.  When talking about external data, it
>> > is far more important for everyone to agree on the same representation
>> > than it is to tailor to each platforms preferences.  That said, rant
>> > away!  I love a good tangent.
>>
>> I guess a good example of what I mean is ELF - the endianness of an
>> ELF image is discoverable, and cross tools do exist -- but because ELF
>> images are strongly bound to their target platform, running the image
>> takes precedence over the simplicity of the tools: so the images are
>> specified in such a way that they can always be host-endian for the
>> machine they run on, without creating format ambiguities.
>
> Yes, there's no technical impediment to making a little-endian dtb
> format.  In fact dtc and libfdt were written with this possibility in
> mind, to the extent that there are hooks / functions in the right
> places to make this reasonably straightforward.
>
> The fact that there are actually two questions here - the endianness
> of the framing dtb format, and the endianness of the property values
> themselves complicates the issue.
>
>> Of course, it's stretching things rather a lot to claim that fdt
>> parsing is performance critical ... or that ELF cross tools work well
>> in all host/target combinations ... rather it's a niggle.
>
> But, there is just no point in creating a variant format.  The
> performance cost is completely negligible (even using the rather
> stupid conversion macros from libfdt which gcc generates horrible code
> for).
>
> The simplicity of having only one variant for tools to deal with wins,
> no contest.

All good arguments, everyone-- thanks for the background.

Like I said, I'm happy for things to stay the way they are.

Cheers
---Dave