renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-16 09:13:55 +08:00
Code

cramfs: rehabilitate it

Browse Source 
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>
This commit is contained in:
Nicolas Pitre 2017-10-12 02:16:13 -04:00 committed by Al Viro
parent eddcd97659
commit 8d59598c35
3 changed files with 50 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
Documentation/filesystems/cramfs.txt
View File

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

4
MAINTAINERS
View File

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

9
fs/cramfs/Kconfig
View File

@ -1,5 +1,5 @@
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.