(CC: Andi Drebes) On Fri, Nov 28, 2008 at 04:54:44PM +0200, Roy Peled wrote: > cramfs is an endianness dependent file system. > So far, the cramfs utilities did not support cramfs > images of different endianness than the host machine. In my mailbox are Andi's patches that implement "little endian only". Unfortunately, it seems that kernel part of Andi's work has been never committed. http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/933 Yes, cramfs is an endianness dependent FS. So, your patch makes sense, but I'd like to see some regression tests before we apply such invasive patch. > +AC_C_BIGENDIAN Ah... nice catch. This AC macro is missing all 2.14.x releases :-( Unfortunately, we don't use this AC macro, but our include/bitops.h depends on WORDS_BIGENDIAN... This is my brown-paper-bag bug :-( Fortunately, this bug affects GPT detection code on big-endian machines in partx(8) and fdisk(8) only. It's minor issue. > +/* > + u32 Endianness swap. > + This algorithm works on both Big endian machines and Little endian machines. > +*/ > +static u32 _swap32(u32 what) > +{ > + int out = 0; > + int i; > + for (i=0;i<sizeof(u32);i++) { > + out <<= 8; > + out |= what&0xff; > + what >>= 8; > + } > + return out; > +} Cannot we use generic macros from include/bitopt.h? I'd like to avoid duplicates. The rest of the patch seems good on the first glance. [Frankly, I hate long function names -- e.g "inode_endianness_from_host". Why not "inode_from_host" ? ... ;-) ] Karel -- Karel Zak <kzak@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
