Commit 99c18ce5 authored by Nicolas Pitre's avatar Nicolas Pitre Committed by Al Viro

cramfs: direct memory access support

Small embedded systems typically execute the kernel code in place (XIP)
directly from flash to save on precious RAM usage. This patch adds to
cramfs the ability to consume filesystem data directly from flash as
well. Cramfs is particularly well suited to this feature as it is very
simple with low RAM usage, and with this feature it is possible to use
it with no block device support and consequently even lower RAM usage.

This patch was inspired by a similar patch from Shane Nay dated 17 years
ago that used to be very popular in embedded circles but never made it
into mainline. This is a cleaned-up implementation that uses far fewer
ifdef's and gets the actual memory location for the filesystem image
via MTD at run time. In the context of small IoT deployments, this
functionality has become relevant and useful again.
Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
Tested-by: default avatarChris Brandt <chris.brandt@renesas.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
parent 8a5776a5
config CRAMFS
tristate "Compressed ROM file system support (cramfs) (OBSOLETE)"
depends on BLOCK
select ZLIB_INFLATE
help
Saying Y here includes support for CramFs (Compressed ROM File
......@@ -20,3 +19,32 @@ config CRAMFS
in terms of performance and features.
If unsure, say N.
config CRAMFS_BLOCKDEV
bool "Support CramFs image over a regular block device" if EXPERT
depends on CRAMFS && BLOCK
default y
help
This option allows the CramFs driver to load data from a regular
block device such a disk partition or a ramdisk.
config CRAMFS_MTD
bool "Support CramFs image directly mapped in physical memory"
depends on CRAMFS && MTD
default y if !CRAMFS_BLOCKDEV
help
This option allows the CramFs driver to load data directly from
a linear adressed 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.
The location of the CramFs image is determined by a
MTD device capable of direct memory mapping e.g. from
the 'physmap' map driver or a resulting MTD partition.
For example, this would mount the cramfs image stored in
the MTD partition named "xip_fs" on the /mnt mountpoint:
mount -t cramfs mtd:xip_fs /mnt
If unsure, say N.
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment