[PATCH 2/2] cramfs: drop obsolete Future Development notes and update tools URL

[Nicolas Pitre <nico@fluxnic.net>]

fs/cramfs/README still carries a "Future Development" section written
around the Linux 2.3.39 era discussing design decisions that have long
since been settled:

  - Block size is 4096 and matches PAGE_SIZE on the reader.
  - Endianness is host-endian; mkcramfs -B / -L handles cross-builds.
  - Block-pointer extensions (CRAMFS_FLAG_EXT_BLOCK_POINTERS) ended up
    being the answer to layout flexibility rather than inode growth.

Drop the stale forward-looking section -- the factual format
description above remains accurate and is kept as-is.

While here, replace the dead sourceforge URL in the "Tools" section
with the current location of the user-space tools on github.

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
 fs/cramfs/README | 92 +-----------------------------------------------
 1 file changed, 1 insertion(+), 91 deletions(-)

diff --git a/fs/cramfs/README b/fs/cramfs/README
index 778df5c4d70b..c0052a11aa28 100644
--- a/fs/cramfs/README
+++ b/fs/cramfs/README
@@ -104,94 +104,4 @@ Tools
 -----
 
 The cramfs user-space tools, including mkcramfs and cramfsck, are
-located at <http://sourceforge.net/projects/cramfs/>.
-
-
-Future Development
-==================
-
-Block Size
-----------
-
-(Block size in cramfs refers to the size of input data that is
-compressed at a time.  It's intended to be somewhere around
-PAGE_SIZE for cramfs_read_folio's convenience.)
-
-The superblock ought to indicate the block size that the fs was
-written for, since comments in <linux/pagemap.h> indicate that
-PAGE_SIZE may grow in future (if I interpret the comment
-correctly).
-
-Currently, mkcramfs #define's PAGE_SIZE as 4096 and uses that
-for blksize, whereas Linux-2.3.39 uses its PAGE_SIZE, which in
-turn is defined as PAGE_SIZE (which can be as large as 32KB on arm).
-This discrepancy is a bug, though it's not clear which should be
-changed.
-
-One option is to change mkcramfs to take its PAGE_SIZE from
-<asm/page.h>.  Personally I don't like this option, but it does
-require the least amount of change: just change `#define
-PAGE_SIZE (4096)' to `#include <asm/page.h>'.  The disadvantage
-is that the generated cramfs cannot always be shared between different
-kernels, not even necessarily kernels of the same architecture if
-PAGE_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:
-
-  1. Always 4096 bytes.
-
-  2. Writer chooses blocksize; kernel adapts but rejects blocksize >
-     PAGE_SIZE.
-
-  3. Writer chooses blocksize; kernel adapts even to blocksize >
-     PAGE_SIZE.
-
-It's easy enough to change the kernel to use a smaller value than
-PAGE_SIZE: just make cramfs_read_folio read multiple blocks.
-
-The cost of option 1 is that kernels with a larger PAGE_SIZE
-value don't get as good compression as they can.
-
-The cost of option 2 relative to option 1 is that the code uses
-variables instead of #define'd constants.  The gain is that people
-with kernels having larger PAGE_SIZE can make use of that if
-they don't mind their cramfs being inaccessible to kernels with
-smaller PAGE_SIZE values.
-
-Option 3 is easy to implement if we don't mind being CPU-inefficient:
-e.g. get read_folio to decompress to a buffer of size MAX_BLKSIZE (which
-must be no larger than 32KB) and discard what it doesn't need.
-Getting read_folio to read into all the covered pages is harder.
-
-The main advantage of option 3 over 1, 2, is better compression.  The
-cost is greater complexity.  Probably not worth it, but I hope someone
-will disagree.  (If it is implemented, then I'll re-use that code in
-e2compr.)
-
-
-Another cost of 2 and 3 over 1 is making mkcramfs use a different
-block size, but that just means adding and parsing a -b option.
-
-
-Inode Size
-----------
-
-Given that cramfs will probably be used for CDs etc. as well as just
-silicon ROMs, it might make sense to expand the inode a little from
-its current 12 bytes.  Inodes other than the root inode are followed
-by filename, so the expansion doesn't even have to be a multiple of 4
-bytes.
+located at <https://github.com/npitre/cramfs-tools>.
-- 
2.53.0