[RFC] Little endian Cramfs on big endian machines?

[RFC] Little endian Cramfs on big endian machines?

[Jon Burgess]

At the moment the cramfs code in 2.4 & 2.5 uses the native machine endianness
for the filesystem layout. I believe this behaviour has been considered a bug
and that the code changed such that the filsystem is always little endian.

There is some code in CVS at http://sourceforge.net/projects/cramfs which
implements this for 2.4. I tried it a couple of months ago and it seemed OK, but
it breaks backwards compatibility with old filesystems on big endian systems so
I suspect it would never be done in a stable kernel series like 2.4. Should
these changes be merged into 2.5?

     Jon

Re: [RFC] Little endian Cramfs on big endian machines?

[John Bradford]

> At the moment the cramfs code in 2.4 & 2.5 uses the native machine
> endianness for the filesystem layout. I believe this behaviour has
> been considered a bug and that the code changed such that the
> filsystem is always little endian.

Maybe the native machine endianness is used for performace reasons -
that would make sense given the typical uses of cramfs.  Also, it is a
read-only filesystem, so a userland application could flip the
endianness if a filesystem needs to be used on a non-native endianness
machine.

I'm not necessarily saying that that it's not a bug, just suggesting
an explaination.

John.

Re: [RFC] Little endian Cramfs on big endian machines?

[Jörn Engel]

On Sat, 1 February 2003 19:29:22 +0000, John Bradford wrote:
> 
> Maybe the native machine endianness is used for performace reasons -
> that would make sense given the typical uses of cramfs.  Also, it is a
> read-only filesystem, so a userland application could flip the
> endianness if a filesystem needs to be used on a non-native endianness
> machine.

Touchy matter.
Having two possible endianness options _will_ cause problems and hours
of lost work, since 50% of all users will get it wrong at least once.
And fixing bugs between keyboard and chair is not a fun job. :)

On the other hand, most filesystem data will be read more than once,
so performance does matter, at least a little.

> I'm not necessarily saying that that it's not a bug, just suggesting
> an explaination.

It is not a bug, it is a tradeoff. Do you want to waste time accessing
the filesystem or fixing so-called bugs and educating the users?

Jörn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong