github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-07-27 01:32:21 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

cramfs: drop obsolete Future Development notes and update tools URL

Browse Source 
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>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260422211039.270552-2-nico@fluxnic.net>
This commit is contained in:
Nicolas Pitre 2026-04-22 17:10:39 -04:00 committed by Jonathan Corbet
parent 077f097219
commit 2367ea8d9d
1 changed files with 1 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
fs/cramfs/README
View File

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