Re: RFC: Host-endian device tree format

On Wed, Jan 19, 2011 at 04:09:39PM +0000, Dave Martin wrote:

On Wed, Jan 19, 2011 at 3:52 PM, Grant Likely [off-list ref] wrote:

quoted

On Wed, Jan 19, 2011 at 8:41 AM, Nicolas Pitre [off-list ref] wrote:

quoted

On Wed, 19 Jan 2011, Dave Martin wrote:

quoted

On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely [off-list ref] wrote:

quoted

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.

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

On Wed, Jan 19, 2011 at 11:47 PM, David Gibson
[off-list ref] wrote:

On Wed, Jan 19, 2011 at 04:09:39PM +0000, Dave Martin wrote:

quoted

On Wed, Jan 19, 2011 at 3:52 PM, Grant Likely [off-list ref] wrote:

quoted

On Wed, Jan 19, 2011 at 8:41 AM, Nicolas Pitre [off-list ref] wrote:

quoted

On Wed, 19 Jan 2011, Dave Martin wrote:

quoted

On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely [off-list ref] wrote:

quoted

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.

quoted

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