[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SG2PR06MB1165C1FB6FB5D43A10FD7D758A9D0@SG2PR06MB1165.apcprd06.prod.outlook.com>
Date: Thu, 31 Aug 2017 02:30:41 +0000
From: Chris Brandt <Chris.Brandt@...esas.com>
To: Nicolas Pitre <nicolas.pitre@...aro.org>,
Alexander Viro <viro@...iv.linux.org.uk>
CC: "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [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:
>
> http://git.linaro.org/people/nicolas.pitre/linux 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 ++
> MAINTAINERS | 4 +-
> 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 <chris.brandt@...esas.com>
Powered by blists - more mailing lists