On Wednesday, August 16, 2017, Nicolas Pitre wrote: > Small embedded systems typically execute the kernel code in place (XIP) > directly from flash to save on precious RAM usage. This adds the ability > to consume filesystem data directly from flash to the cramfs filesystem > as well. Cramfs is particularly well suited to this feature as it is > very simple and its RAM usage is already very low, and with this feature > it is possible to use it with no block device support and 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 > memory address at run time when both methods are configured in. In the > context of small IoT deployments, this functionality has become relevant > and useful again. > > To distinguish between both access types, the cramfs_physmem filesystem > type must be specified when using a memory accessible cramfs image, and > the physaddr argument must provide the actual filesystem image's physical > memory location. > > Signed-off-by: Nicolas Pitre <[email protected]> > --- > fs/cramfs/Kconfig | 30 ++++++- > fs/cramfs/inode.c | 264 +++++++++++++++++++++++++++++++++++++++++++------ > ----- > 2 files changed, 242 insertions(+), 52 deletions(-) > > diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig > index 11b29d491b..5eed4ad2d5 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. > +
trailing whitespace > +config CRAMFS_PHYSMEM > + bool "Support CramFs image directly mapped in physical memory" > + depends on CRAMFS > + 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 filesystem type for this feature is "cramfs_physmem". > + The location of the CramFs image in memory is board > + dependent. Therefore, if you say Y, you must know the proper > + physical address where to store the CramFs image and specify > + it using the physaddr=0x******** mount option (for example: > + "mount -t cramfs_physmem -o physaddr=0x100000 none /mnt"). > + > + If unsure, say N. > + new blank line at EOF -Chris
