Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

cramfs: rehabilitate it

Update documentation, pointer to latest tools, appoint myself as
maintainer. Given it's been unloved for so long, I don't expect anyone
will protest.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Chris Brandt <chris.brandt@renesas.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

authored by

Nicolas Pitre and committed by
Al Viro
8d59598c eddcd976

+50 -5
+42
Documentation/filesystems/cramfs.txt
··· 45 45 mind the filesystem becoming unreadable to future kernels. 46 46 47 47 48 + Memory Mapped cramfs image 49 + -------------------------- 50 + 51 + The CRAMFS_MTD Kconfig option adds support for loading data directly from 52 + a physical linear memory range (usually non volatile memory like Flash) 53 + instead of going through the block device layer. This saves some memory 54 + since no intermediate buffering is necessary to hold the data before 55 + decompressing. 56 + 57 + And when data blocks are kept uncompressed and properly aligned, they will 58 + automatically be mapped directly into user space whenever possible providing 59 + eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped 60 + read-write (hence they have to be copied to RAM) may still be compressed in 61 + the cramfs image in the same file along with non compressed read-only 62 + segments. Both MMU and no-MMU systems are supported. This is particularly 63 + handy for tiny embedded systems with very tight memory constraints. 64 + 65 + The location of the cramfs image in memory is system dependent. You must 66 + know the proper physical address where the cramfs image is located and 67 + configure an MTD device for it. Also, that MTD device must be supported 68 + by a map driver that implements the "point" method. Examples of such 69 + MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap 70 + (Flash device in physical memory map). MTD partitions based on such devices 71 + are fine too. Then that device should be specified with the "mtd:" prefix 72 + as the mount device argument. For example, to mount the MTD device named 73 + "fs_partition" on the /mnt directory: 74 + 75 + $ mount -t cramfs mtd:fs_partition /mnt 76 + 77 + To boot a kernel with this as root filesystem, suffice to specify 78 + something like "root=mtd:fs_partition" on the kernel command line. 79 + 80 + 81 + Tools 82 + ----- 83 + 84 + A version of mkcramfs that can take advantage of the latest capabilities 85 + described above can be found here: 86 + 87 + https://github.com/npitre/cramfs-tools 88 + 89 + 48 90 For /usr/share/magic 49 91 -------------------- 50 92
+2 -2
MAINTAINERS
··· 3676 3676 F: include/linux/cpuidle.h 3677 3677 3678 3678 CRAMFS FILESYSTEM 3679 - W: http://sourceforge.net/projects/cramfs/ 3680 - S: Orphan / Obsolete 3679 + M: Nicolas Pitre <nico@linaro.org> 3680 + S: Maintained 3681 3681 F: Documentation/filesystems/cramfs.txt 3682 3682 F: fs/cramfs/ 3683 3683
+6 -3
fs/cramfs/Kconfig
··· 1 1 config CRAMFS 2 - tristate "Compressed ROM file system support (cramfs) (OBSOLETE)" 2 + tristate "Compressed ROM file system support (cramfs)" 3 3 select ZLIB_INFLATE 4 4 help 5 5 Saying Y here includes support for CramFs (Compressed ROM File ··· 15 15 cramfs. Note that the root file system (the one containing the 16 16 directory /) cannot be compiled as a module. 17 17 18 - This filesystem is obsoleted by SquashFS, which is much better 19 - in terms of performance and features. 18 + This filesystem is limited in capabilities and performance on 19 + purpose to remain small and low on RAM usage. It is most suitable 20 + for small embedded systems. If you have ample RAM to spare, you may 21 + consider a more capable compressed filesystem such as SquashFS 22 + which is much better in terms of performance and features. 20 23 21 24 If unsure, say N. 22 25