> > Endian-independent code is slower than wrong-endian code, because of the > > necessary conditionals. Thus, you DO NOT WANT this(*). > > I'd prefer not to have it either. But a someone (pinhead) was smart > enough not to define an endianess for cramfs from the beginning we're > stuck with it. Indeed, this is the problem. The readme file fs/cramfs/README states: "One part of that is addressing endianness. The two options here are `always use little-endian' (like ext2fs) or `writer chooses endianness; kernel adapts at runtime'. Little-endian wins because of code simplicity and little CPU overhead even on big-endian machines." Unfortunately, the better idea was never implemented. Further, there's no information about the endianness stored in the filesystem. Guessing it and mounting the filesystem isn't a clean solution. Even worse, there's no information about which compression algorithm was used to create the filesystem. Guessing the compression method may lead to serious problems. So here is my proposal for future development of cramfs: The should tell cramfs how to mount a filesystem. Therefore, the endianness and the compression method both have to be specified manually. If none is specified, cramfs will assume host endianness and that deflate can be used in order to decompress the contents. If something seems to be wrong with the filesystem (e.g. wrong magic), cramfs will guess the endianness and inform the user about the guess, but it won't mount the filesystem if it doesn't match the endianness specified or the host's one. Andi - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
