summaryrefslogtreecommitdiff
path: root/fs/cramfs/Kconfig
diff options
context:
space:
mode:
authorNicolas Pitre <nicolas.pitre@linaro.org>2017-10-13 23:09:23 +0300
committerAl Viro <viro@zeniv.linux.org.uk>2017-10-15 07:47:21 +0300
commit99c18ce580c6cc6763e694b4ce320d7b226ab59b (patch)
tree4e717d01235265c06eb27b64d6b3618590dbc009 /fs/cramfs/Kconfig
parent8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (diff)
downloadlinux-99c18ce580c6cc6763e694b4ce320d7b226ab59b.tar.xz
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: Nicolas Pitre <nico@linaro.org> Tested-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/cramfs/Kconfig')
-rw-r--r--fs/cramfs/Kconfig30
1 files changed, 29 insertions, 1 deletions
diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
index 11b29d491b7c..ef86b06bc064 100644
--- a/fs/cramfs/Kconfig
+++ b/fs/cramfs/Kconfig
@@ -1,6 +1,5 @@
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.