[lkml]   [2017]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH v2 0/5] cramfs refresh for embedded usage
On Wednesday, August 16, 2017, Nicolas Pitre wrote:
> This series brings a nice refresh to the cramfs filesystem, adding the
> following capabilities:
> - Direct memory access, bypassing the block and/or MTD layers entirely.
> - Ability to store individual data blocks uncompressed.
> - Ability to locate individual data blocks anywhere in the filesystem.
> The end result is a very tight filesystem that can be accessed directly
> from ROM without any other subsystem underneath. Also this allows for
> user space XIP which is a very important feature for tiny embedded
> systems.
> Why cramfs?
> Because cramfs is very simple and small. With CONFIG_CRAMFS_BLOCK=n and
> CONFIG_CRAMFS_PHYSMEM=y the cramfs driver may use as little as 3704
> bytes
> of code. That's many times smaller than squashfs. And the runtime memory
> usage is also much less with cramfs than squashfs. It packs very tightly
> already compared to romfs which has no compression support. And the
> cramfs
> format was simple to extend, allowing for both compressed and
> uncompressed
> blocks within the same file.
> Why not accessing ROM via MTD?
> The MTD layer is nice and flexible. It also represents a huge overhead
> considering its core with no other enabled options weights 19KB.
> That's many times the size of the cramfs code for something that
> essentially boils down to a glorified argument parser and a call to
> memremap() in this case. And if someone still wants to use cramfs via
> MTD then it is already possible with mtdblock.
> Why not using DAX?
> DAX stands for "Direct Access" and is a generic kernel layer helping
> with the necessary tasks involved with XIP. It is tailored for large
> writable filesystems and relies on the presence of an MMU. It also has
> the following shortcoming: "The DAX code does not work correctly on
> architectures which have virtually mapped caches such as ARM, MIPS and
> SPARC." That makes it unsuitable for a large portion of the intended
> targets for this series. And due to the read-only nature of cramfs, it
> is
> possible to achieve the intended result with a much simpler approach
> making
> DAX somewhat overkill in this context.
> The maximum size of a cramfs image can't exceed 272MB. In practice it is
> likely to be much much less. Given this series is concerned with small
> memory systems, even in the MMU case there is always plenty of vmalloc
> space left to map it all and even a 272MB memremap() wouldn't be a
> problem. If it is then maybe your system is big enough with large
> resources to manage already and you're pretty unlikely to be using cramfs
> in the first place.
> Of course, while this cramfs remains backward compatible with existing
> filesystem images, a newer mkcramfs version is necessary to take advantage
> of the extended data layout. I created a version of mkcramfs that
> detects ELF files and marks text+rodata segments for XIP and compresses
> the
> rest of those ELF files automatically.
> So here it is. I'm also willing to step up as cramfs maintainer given
> that no sign of any maintenance activities appeared for years.
> This series is also available based on v4.13-rc4 via git here:
> xipcramfs
> Changes from v1:
> - Improved mmap() support by adding the ability to partially populate a
> mapping and lazily split the non directly mapable pages to a separate
> vma at fault time (thanks to Chris Brandt for testing).
> - Clarified the documentation some more.
> diffstat:
> Documentation/filesystems/cramfs.txt | 42 ++
> fs/cramfs/Kconfig | 39 +-
> fs/cramfs/README | 31 +-
> fs/cramfs/inode.c | 621 +++++++++++++++++++++++++----
> include/uapi/linux/cramfs_fs.h | 20 +-
> init/do_mounts.c | 8 +
> 7 files changed, 688 insertions(+), 77 deletions(-)

For this whole series:

Tested-by: Chris Brandt <>

 \ /
  Last update: 2017-08-31 04:31    [W:0.124 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site