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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
