Date:   Thu, 12 Oct 2017 02:16:09 -0400
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Alexander Viro <viro@...iv.linux.org.uk>,
        Christoph Hellwig <hch@...radead.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-embedded@...r.kernel.org, linux-kernel@...r.kernel.org,
        Chris Brandt <Chris.Brandt@...esas.com>
Subject: [PATCH v6 0/4] cramfs refresh for embedded usage

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. This also allows for
user space XIP which is a very important feature for tiny embedded
systems.

This series is also available based on v4.14-rc3 via git here:

  http://git.linaro.org/people/nicolas.pitre/linux xipcramfs

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.

Does it use MTD or not?

  The MTD layer is used to get at the actual physical/virtual address
  for the filesystem image. The underlying MTD device (or a partition
  based on it) specified as mount argument must use a driver that
  implements the mtd->_point method. Once mtd_point() is successful,
  all accesses are performed directly in memory and the MTD layer is
  no longer involved. Patches adding point support to a few more MTD
  drivers can be found here:

    http://git.linaro.org/people/nicolas.pitre/linux mtd_point

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.


Changes from v5:

- Switch to MTD for obtaining the cramfs image memory address rather than
  accepting a physical address directly as a mount argument.
- Drop the patch for making root mount possible as the MTD mount case is
  already supported and that covers our usage.
- There is no longer a separate filesystem type. It is "cramfs" for both
  blockdev based and MTD/memory based accesses.
- Fix NULL deref in cramfs_statfs() when using direct memory access.

Changes from v4:

- Remove fault handler with vma splitting code in favor of VM_MIXEDMAP for
  much simpler code. Thanks to Christoph Hellwig for review and suggestions.
- Additional code cleanups, mostly from Christoph's suggestions.

Changes from v3:

- Rebased on v4.13.
- Made direct access depend on cramfs not being modular due to unexported
  vma handling functions.
- Solicit comments from mm people explicitly.

Changes from v2:

- Plugged a few races in cramfs_vmasplit_fault(). Thanks to Al Viro for
  highlighting them.
- Fixed some checkpatch warnings

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                    | 514 +++++++++++++++++++++++++----
 include/uapi/linux/cramfs_fs.h       |  26 +-
 6 files changed, 587 insertions(+), 69 deletions(-)

Powered by blists - more mailing lists