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