From: Andi Drebes Update 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 Signed-off-by: Andrew Morton --- fs/cramfs/README | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff -puN fs/cramfs/README~cramfs-update-documentation fs/cramfs/README --- a/fs/cramfs/README~cramfs-update-documentation +++ a/fs/cramfs/README @@ -6,8 +6,11 @@ a bit looser, e.g. it doesn't care if th 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. : @@ -108,18 +111,6 @@ kernels, not even necessarily kernels of 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: _