The following patch updates the cramfs documentation according to the changes in PATCH 1/2.
The changes were tested on the following types of machines:
An i386 compatible box (little endian)
UltraSparc IIi (big endian)
Signed-off-by: Andi Drebes <andi@xxxxxxxxxxxxxxxxxxx>
---
README | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/fs/cramfs/README b/fs/cramfs/README
index 445d1c2..91efe77 100644
--- a/fs/cramfs/README
+++ b/fs/cramfs/README
@@ -6,8 +6,11 @@ a bit looser, e.g. it doesn't care if the <file_data> items are
swapped around (though it does care that directory entries (inodes) in
a given directory are contiguous, as this is used by readdir).
-All data is currently in host-endian format; neither mkcramfs nor the
-kernel ever do swabbing. (See section `Block Size' below.)
+All data is now in little endian format. Before, it was in host endian
+format. In order to make filesystem images more shareable between machines
+with a different byte order, cramfs' specification ("this README file")
+was updated. There will be no support for big endian filesystems in the
+future.
<filesystem>:
<superblock>
@@ -108,18 +111,6 @@ kernels, not even necessarily kernels of the same architecture if
PAGE_CACHE_SIZE is subject to change between kernel versions
(currently possible with arm and ia64).
-The remaining options try to make cramfs more sharable.
-
-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.
-
-The cost of swabbing is changing the code to use the le32_to_cpu
-etc. macros as used by ext2fs. We don't need to swab the compressed
-data, only the superblock, inodes and block pointers.
-
-
The other part of making cramfs more sharable is choosing a block
size. The options are:
-
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
