From: Chris Brandt <Chris.Brandt@renesas.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>,
Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 1/5] cramfs: direct memory access support
Date: Wed, 16 Aug 2017 18:28:15 +0000 [thread overview]
Message-ID: <SG2PR06MB1165518B81E3855C36CBC9A18A820@SG2PR06MB1165.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <20170816173536.1879-2-nicolas.pitre@linaro.org>
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
next prev parent reply other threads:[~2017-08-16 18:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 17:35 [PATCH v2 0/5] cramfs refresh for embedded usage Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 1/5] cramfs: direct memory access support Nicolas Pitre
2017-08-16 18:28 ` Chris Brandt [this message]
2017-08-16 19:44 ` Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 2/5] cramfs: make cramfs_physmem usable as root fs Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning Nicolas Pitre
2017-08-16 18:28 ` Chris Brandt
2017-08-16 17:35 ` [PATCH v2 4/5] cramfs: add mmap support Nicolas Pitre
2017-08-16 18:28 ` Chris Brandt
2017-08-28 6:46 ` Al Viro
2017-08-28 13:29 ` Nicolas Pitre
2017-08-28 14:23 ` Al Viro
2017-08-28 19:17 ` Nicolas Pitre
2017-08-29 19:38 ` Chris Brandt
2017-08-29 20:00 ` Nicolas Pitre
2017-08-29 20:11 ` Chris Brandt
2017-08-31 2:29 ` Chris Brandt
2017-08-16 17:35 ` [PATCH v2 5/5] cramfs: rehabilitate it Nicolas Pitre
2017-08-31 2:30 ` [PATCH v2 0/5] cramfs refresh for embedded usage Chris Brandt
2017-08-31 3:03 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SG2PR06MB1165518B81E3855C36CBC9A18A820@SG2PR06MB1165.apcprd06.prod.outlook.com \
--to=chris.brandt@renesas.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).