RE: [PATCH v2 1/5] cramfs: direct memory access support

[Nicolas Pitre]

On Wed, 16 Aug 2017, Chris Brandt wrote:

> On Wednesday, August 16, 2017, Nicolas Pitre wrote:
> > +   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

Yeah... Fixed it and the others in my git repo, thanks.
This is something that can be done with git apply --whitespace=fix so I 
won't repost unless I get more comments.


Nicolas

RE: [PATCH v2 1/5] cramfs: direct memory access support

[Nicolas Pitre]

On Wed, 16 Aug 2017, Chris Brandt wrote:

> On Wednesday, August 16, 2017, Nicolas Pitre wrote:
> > +   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

Yeah... Fixed it and the others in my git repo, thanks.
This is something that can be done with git apply --whitespace=fix so I 
won't repost unless I get more comments.


Nicolas

RE: [PATCH v2 1/5] cramfs: direct memory access support

[Chris Brandt]

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 
> ---
>  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=0x10 none /mnt").
> +
> +   If unsure, say N.
> +


new blank line at EOF



-Chris

RE: [PATCH v2 1/5] cramfs: direct memory access support

[Chris Brandt]

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 
> ---
>  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=0x10 none /mnt").
> +
> +   If unsure, say N.
> +


new blank line at EOF



-Chris