On Wed, Jan 19, 2011 at 11:47 PM, David Gibson <[email protected]> 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 <[email protected]> >> wrote: >> > On Wed, Jan 19, 2011 at 8:41 AM, Nicolas Pitre <[email protected]> >> > wrote: >> >> On Wed, 19 Jan 2011, Dave Martin wrote: >> >>> On Wed, Jan 19, 2011 at 1:41 PM, Grant Likely >> >>> <[email protected]> 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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
