From patchwork Fri Aug 11 19:22:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 109923 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp1340457qge; Fri, 11 Aug 2017 12:31:39 -0700 (PDT) X-Received: by 10.98.156.145 with SMTP id u17mr16930972pfk.136.1502479898950; Fri, 11 Aug 2017 12:31:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502479898; cv=none; d=google.com; s=arc-20160816; b=jC+UDEDZtDBUeUyO8H9HF4Dx/6CA8c4eYLOshkDzhJO06iq+G+0Ivcdvq7neavRT6F O0fheq5BKcsPpp17ZSVLwrrvwxu7OHp3XGmUZQ1mFwT//IWvO5+2SaPxdkdCy3XDgypH FIsRfX4eiyQ3d0jSlRhDqNGcEX9qAshgbvRSykN/KhmcMlpT9t+O4fUG9GQYPxJdhgnT eIupwv/RLBJ7hncd8uMEzVWkewGVlUvBvwluBbfRZkOk6GAWfIB+mt0LVXppvBhrW6U2 CJA3YdRHM6xB+51tiTeTdyqvLLYrRtiW16XT/OVAgdxqYk2mFhvQPFDKu1CBo75Mx8jn 5c/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=HFtqx1KMvBcYIXKvcHGJe91nNEYIAPei2ysjnC9dquw=; b=T2fK2kIKrnFEpjQMmCpHlnqan4XbMGCe1y+D649Da56hg/ftTGu2qikM3C3vu8HKY0 GUkaqjDmRYVYDbv5WS3MFGsCxxk16k9Easy5QGgCkDnhEjWDhfIGKTd3CVD2DdUsCjnP /1RmnIuozCLCesiilmCAME5KZgIJUmhQnZ9ukAeTiRz+lqxR0BBb4EOyqYJJHlBaXLKT cwQ0AswCYpiZWVzUDI7tS8G3AM9vfXjj5FRNjUZO0k8c8xNpR3EiyprB+fKLTIK3RrXt Q0nwlTdZ2XZD0AUYK82+coZZm+uyv97oxFiiEVMcWhZF82nk1VDrE3mjncZoVWd6bWFN pfwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=a0g4ECWH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f26si862382pge.723.2017.08.11.12.31.38; Fri, 11 Aug 2017 12:31:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=a0g4ECWH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753738AbdHKTbA (ORCPT + 25 others); Fri, 11 Aug 2017 15:31:00 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:62961 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753381AbdHKTa5 (ORCPT ); Fri, 11 Aug 2017 15:30:57 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B697BA4264; Fri, 11 Aug 2017 15:23:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:date:message-id; s=sasl; bh=adGWYbE458GrU/EY8ac43Mpjr3Y =; b=a0g4ECWH/k/kPBe3H1ko7n+8ITScvvBPcgF/xUC36wk7HE7oUSI+E7a4auS OIAchyNpX29pfgf5pWKDuVO3U7vEXH3po4YWGlSgmoC9hT20TOTkRs1QFu44eunj 9utmZ1j5pnNLxlTqMoeleE9+mxnGlFPhbPeTLqJ1EEcYlh+Q= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7ECC7A4263; Fri, 11 Aug 2017 15:23:01 -0400 (EDT) Received: from yoda.home (unknown [96.23.157.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 28C33A4259; Fri, 11 Aug 2017 15:23:00 -0400 (EDT) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTP id 319452DA0670; Fri, 11 Aug 2017 15:22:59 -0400 (EDT) From: Nicolas Pitre To: Alexander Viro Cc: linux-fsdevel@vger.kernel.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Brandt Subject: [PATCH 0/5] cramfs refresh for embedded usage Date: Fri, 11 Aug 2017 15:22:47 -0400 Message-Id: <20170811192252.19062-1-nicolas.pitre@linaro.org> X-Mailer: git-send-email 2.9.4 X-Pobox-Relay-ID: 7CE37AE8-7ECA-11E7-9B63-9D2B0D78B957-78420484!pb-smtp2.pobox.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-)