Re: cramfs in big endian

[Andi Drebes <lists-receive@programmierforen.de>]

> > 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