Thread (1 message) 1 message, 1 author, 2011-01-19

Re: RFC: Host-endian device tree format

From: Dave Martin <hidden>
Date: 2011-01-19 16:09:39
Also in: linux-arm-kernel

On Wed, Jan 19, 2011 at 3:52 PM, Grant Likely [off-list ref] wrote:
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.

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.

So, I'm happy as-is.  It was just tempting to rock the boat a bit to
make sure everyone has their sea legs :)

Cheers
---Dave
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help