mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Pitre <nicolas.pitre@linaro.org>
To: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-embedded@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Chris Brandt <Chris.Brandt@renesas.com>
Subject: [PATCH 0/5] cramfs refresh for embedded usage
Date: Fri, 11 Aug 2017 15:22:47 -0400	[thread overview]
Message-ID: <20170811192252.19062-1-nicolas.pitre@linaro.org> (raw)

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 only 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().  And if someone still wants to use cramfs via MTD then
it is already possible with mtdblock.

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 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

diffstat:

 Documentation/filesystems/cramfs.txt |  35 ++
 MAINTAINERS                          |   4 +-
 fs/cramfs/Kconfig                    |  39 ++-
 fs/cramfs/README                     |  31 +-
 fs/cramfs/inode.c                    | 500 +++++++++++++++++++++++++----
 include/uapi/linux/cramfs_fs.h       |  20 +-
 init/do_mounts.c                     |   8 +
 7 files changed, 560 insertions(+), 77 deletions(-)

             reply	other threads:[~2017-08-11 19:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 19:22 Nicolas Pitre [this message]
2017-08-11 19:22 ` [PATCH 1/5] cramfs: direct memory access support Nicolas Pitre
2017-08-12  7:49   ` Christoph Hellwig
2017-08-14  2:29     ` Nicolas Pitre
2017-08-11 19:22 ` [PATCH 2/5] cramfs: make cramfs_physmem usable as root fs Nicolas Pitre
2017-08-11 19:22 ` [PATCH 3/5] cramfs: implement uncompressed and arbitrary data block positioning Nicolas Pitre
2017-08-11 19:22 ` [PATCH 4/5] cramfs: add mmap support Nicolas Pitre
2017-08-11 19:22 ` [PATCH 5/5] cramfs: rehabilitate it Nicolas Pitre
2017-08-14 17:11 ` [PATCH 0/5] cramfs refresh for embedded usage Chris Brandt
2017-08-14 17:31   ` Nicolas Pitre
2017-08-14 18:01     ` Chris Brandt
2017-08-14 18:17       ` Nicolas Pitre
2017-08-14 18:37         ` Chris Brandt
2017-08-15  4:10           ` Nicolas Pitre
2017-08-15 11:00             ` Chris Brandt
2017-08-16  5:10               ` Nicolas Pitre
2017-08-16 11:08                 ` Chris Brandt
2017-08-16 14:29                   ` Nicolas Pitre
2017-08-16 15:12                     ` Chris Brandt
2017-08-17  1:17                       ` 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=20170811192252.19062-1-nicolas.pitre@linaro.org \
    --to=nicolas.pitre@linaro.org \
    --cc=Chris.Brandt@renesas.com \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®