On Tue, Dec 22, 2009 at 03:56:55PM -0500, Robert P. J. Day wrote: > > perhaps showing my ignorance of how big vs little endian should be > implemented, but in configuring and building the sandbox version, i > get: > > ... > CC common/environment.o > In file included from common/environment.c:37: > include/envfs.h:47:23: warning: "__BIG_ENDIAN" is not defined > ... > > this isn't surprising since, as i read it, because this is x86_64, > it's the little-endian headers that are included, but the envfs.h > header contains the preprocessor checking: > > #ifndef __BYTE_ORDER > #error "No byte order defined in __BYTE_ORDER" > #endif > > #if __BYTE_ORDER == __LITTLE_ENDIAN > ... snip ... > #elif __BYTE_ORDER == __BIG_ENDIAN > ... snip ... > > clearly(?), depending on which endianness is being used, one or the > other of __LITTLE_ENDIAN or __BIG_ENDIAN won't be defined, right? so, > no matter what, *one* of those tests is going to generate a warning. Hm, in glibc both are defined like this: #define __LITTLE_ENDIAN 1234 #define __BIG_ENDIAN 4321 In the kernel (and barebox too) only one of them is defined depending on the endianess. I wonder why we do not define both, too. Digging a bit further... This part of include/envfs.h is copied from include/cramfs/cramfs_fs.h. The cramfs header file is copied from U-Boot, but as the U-Boot guys found out cramfs is always in host order and thus does not need byteswap functions (see http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/22846) But that's another story, I think we should keep the environment in little endian order to be able to generate a envfs image on the compile host. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
