Re: cramfs in big endian

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

Christoph Hellwig wrote:
> On Wed, Nov 07, 2007 at 09:51:48PM +0100, Andi Drebes wrote:
>> Hi!
>>
>>> I would suggest you to use squashfs instead of cramfs.
>>> First, it's newer, it's better, it's actively developed, it doesn't have any
>>> limits like the bad cramfs. 
>> I'm developing a new linux based firmware for my router which uses cramfs. 
>> Switching to squashfs still needs some time. Meanwhile, I have to work with 
>> cramfs. As the router uses the big endian format and as my machine works with 
>> the little endian format, I'm unable to mount the router's filesystem images.
> 
> Making cramfs endianess-independent shouldn't be much work.  Take a look
> at the helpers in fs/ufs/swab.h and use them for every ondisk access in
> cramfs.  Drop me a not if you need some help.

And it would suck.  Hard.

Endian-independent code is slower than wrong-endian code, because of the 
necessary conditionals.  Thus, you DO NOT WANT this(*).

The only way to not make it totally suck is to compile the code twice 
and do switching at a VERY high level -- in effect, creating two 
separate filesystem drivers.

	-hpa

(*) Readonly filesystems like iso9660 have attempted to be 
*both*-endian, by having its datastructures in both forms at all times. 
    That is inefficient with space, but would be CPU-efficient in 
theory.  Unfortunately it causes output validation problems; apparently 
many iso9660 mastering programs output invalid bigendian information as 
it is never tested; consequently, many bigendian platforms read the 
littleendian information anyway.