Re: cramfs in big endian

["H. Peter Anvin" <hpa@zytor.com>]

Andi Drebes wrote:
> 
> 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.
> 

What about simply deep-sixing cramfs and replacing it with squashfs or 
something else?

	-hpa