Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8d59598c authored by Nicolas Pitre's avatar Nicolas Pitre Committed by Al Viro
Browse files

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: default avatarNicolas Pitre <nico@linaro.org>
Tested-by: default avatarChris Brandt <chris.brandt@renesas.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
parent eddcd976

Documentation/filesystems/cramfs.txt

+42 −0
Original line number Diff line number Diff line
@@ -45,6 +45,48 @@ you can just change the #define in mkcramfs.c, so long as you don't 
mind the filesystem becoming unreadable to future kernels.





Memory Mapped cramfs image

--------------------------



The CRAMFS_MTD Kconfig option adds support for loading data directly from

a physical linear memory range (usually non volatile memory like Flash)

instead of going through the block device layer. This saves some memory

since no intermediate buffering is necessary to hold the data before

decompressing.



And when data blocks are kept uncompressed and properly aligned, they will

automatically be mapped directly into user space whenever possible providing

eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped

read-write (hence they have to be copied to RAM) may still be compressed in

the cramfs image in the same file along with non compressed read-only

segments. Both MMU and no-MMU systems are supported. This is particularly

handy for tiny embedded systems with very tight memory constraints.



The location of the cramfs image in memory is system dependent. You must

know the proper physical address where the cramfs image is located and

configure an MTD device for it. Also, that MTD device must be supported

by a map driver that implements the "point" method. Examples of such

MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap

(Flash device in physical memory map). MTD partitions based on such devices

are fine too. Then that device should be specified with the "mtd:" prefix

as the mount device argument. For example, to mount the MTD device named

"fs_partition" on the /mnt directory:



$ mount -t cramfs mtd:fs_partition /mnt



To boot a kernel with this as root filesystem, suffice to specify

something like "root=mtd:fs_partition" on the kernel command line.





Tools

-----



A version of mkcramfs that can take advantage of the latest capabilities

described above can be found here:



https://github.com/npitre/cramfs-tools





For /usr/share/magic

--------------------

MAINTAINERS

+2 −2
Original line number Diff line number Diff line
@@ -3676,8 +3676,8 @@ F: drivers/cpuidle/* 
F:	include/linux/cpuidle.h



CRAMFS FILESYSTEM

W:	http://sourceforge.net/projects/cramfs/

S:	Orphan / Obsolete

M:	Nicolas Pitre <nico@linaro.org>

S:	Maintained

F:	Documentation/filesystems/cramfs.txt

F:	fs/cramfs/

fs/cramfs/Kconfig

+6 −3
Original line number Diff line number Diff line 
config CRAMFS

	tristate "Compressed ROM file system support (cramfs) (OBSOLETE)"

	tristate "Compressed ROM file system support (cramfs)"

	select ZLIB_INFLATE

	help

	  Saying Y here includes support for CramFs (Compressed ROM File
@@ -15,8 +15,11 @@ config CRAMFS 
	  cramfs.  Note that the root file system (the one containing the

	  directory /) cannot be compiled as a module.



	  This filesystem is obsoleted by SquashFS, which is much better

	  in terms of performance and features.

	  This filesystem is limited in capabilities and performance on

	  purpose to remain small and low on RAM usage. It is most suitable

	  for small embedded systems. If you have ample RAM to spare, you may

	  consider a more capable compressed filesystem such as SquashFS

	  which is much better in terms of performance and features.



	  If unsure, say N.