lkml.org 
[lkml]   [2017]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH v2 1/5] cramfs: direct memory access support
    Date
    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 <nico@linaro.org>
    > ---
    > 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

    \
     
     \ /
      Last update: 2017-08-16 20:29    [W:4.085 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site