From patchwork Thu Oct 12 06:16:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 115578 Delivered-To: patch@linaro.org Received: by 10.140.22.163 with SMTP id 32csp1575101qgn; Wed, 11 Oct 2017 23:16:51 -0700 (PDT) X-Google-Smtp-Source: AOwi7QD9D8ze6dO/xWoBatvXw8q7zyVr2fc9n0fDm0jvqggzDJLdA8/mjcNckAOmDfIlJlpk/PYu X-Received: by 10.101.93.65 with SMTP id e1mr1263300pgt.150.1507789010949; Wed, 11 Oct 2017 23:16:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507789010; cv=none; d=google.com; s=arc-20160816; b=yMgOd1frHKvNNEAoqA/eco4XGKSDLpuN+8JKv6Sk6LfosiEO3Nv8A/B6eu8mVV6hzx +1ABcjf1nxsTYM9B8Dhua4gh12EQY7jTpzodjofV4IBOmvBroZeRNO7/mUJho8QaSNdu DnmGNZihHEK9WwbZu21N+0jPbvPrAUl3rJEOEhWtW+oy8q9eeUjHJ92LhXaZVIyKOxsV VGxaQEy2E1UIFaLGs1+qpvGZYZFy4YiVQd8eAP9jySJjXkFFM0OXuD6EJ6nYBFh+mlAo afCBMUCaK4pR45detc0OXeQoPdSVViwrCiy99WMLxP6cNBwEqvRy0qcJkdWJppXd8zwO dycg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=7uAOASj+qyvt4VixU9DrP7Bz9TCnWJ2J7MhnA1BLnk0=; b=OwtPdS5cAgR00/J8aBPTmfh93ab9uioheg64zgsvSIRQwPlaFsoS9Dx4njgMYAH1s5 mlclxg5XWQNxqUodtKGIEiUYszSLVXLRWuBJ7KmnmIhYggFKRZv3Gh04K8N8x2Tv5GT7 o7cyL9E1PA/INB6kR2jrrs7TliXRv6M9Wucyo0z3fRiTi3ISwfqB0iRCDnZam29YNd+R dEjaPufGlZCc1iIPFzHtQEL0s42x2n6aeUDMU+XIPJoYcKV+IKqyiZChSOrQTR8RzaX6 QI+kr9XLHid+QfoeeM11ss3xZYAd/LSwuSL08bMyWQp64AbLr1BKUwKsN/Mvz6g4dJQK OL4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pobox.com header.s=sasl header.b=Sq2wkXAA; 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 64si2134909ply.756.2017.10.11.23.16.50; Wed, 11 Oct 2017 23:16:50 -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=Sq2wkXAA; 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 S1752446AbdJLGQs (ORCPT + 27 others); Thu, 12 Oct 2017 02:16:48 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:51655 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751659AbdJLGQo (ORCPT ); Thu, 12 Oct 2017 02:16:44 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 23E809C414; Thu, 12 Oct 2017 02:16:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:date:message-id:in-reply-to:references; s=sasl; bh=qsrI 3vSj7UfszHua+aKmwwWh8oY=; b=Sq2wkXAARlZSoehN6pTwYbLIPN7Dl8QCMcZA GblwF61hkcFfgmQ8jNhlT7nd5EKgKZTj5oEgiOqDukXiHf0TYkgbL/FbM4UD2qv9 i5/h9zrZ4euJ9OY1K/STOiZALYEg4pTos6Ei2GweSVFUoh+hN+t0opc0tveIwQIF 7jTRGGU= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1BC199C413; Thu, 12 Oct 2017 02:16:44 -0400 (EDT) Received: from yoda.home (unknown [137.175.234.45]) (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 A8A849C40C; Thu, 12 Oct 2017 02:16:43 -0400 (EDT) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTP id CF2A92DA06C1; Thu, 12 Oct 2017 02:16:42 -0400 (EDT) From: Nicolas Pitre To: Alexander Viro , Christoph Hellwig Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Brandt Subject: [PATCH v6 4/4] cramfs: rehabilitate it Date: Thu, 12 Oct 2017 02:16:13 -0400 Message-Id: <20171012061613.28705-5-nicolas.pitre@linaro.org> X-Mailer: git-send-email 2.9.5 In-Reply-To: <20171012061613.28705-1-nicolas.pitre@linaro.org> References: <20171012061613.28705-1-nicolas.pitre@linaro.org> X-Pobox-Relay-ID: EB207162-AF14-11E7-B841-575F0C78B957-78420484!pb-smtp2.pobox.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update documentation, pointer to latest tools, appoint myself as maintainer. Given it's been unloved for so long, I don't expect anyone will protest. Signed-off-by: Nicolas Pitre Tested-by: Chris Brandt --- Documentation/filesystems/cramfs.txt | 42 ++++++++++++++++++++++++++++++++++++ MAINTAINERS | 4 ++-- fs/cramfs/Kconfig | 9 +++++--- 3 files changed, 50 insertions(+), 5 deletions(-) -- 2.9.5 diff --git a/Documentation/filesystems/cramfs.txt b/Documentation/filesystems/cramfs.txt index 4006298f67..8e19a53d64 100644 --- a/Documentation/filesystems/cramfs.txt +++ b/Documentation/filesystems/cramfs.txt @@ -45,6 +45,48 @@ you can just change the #define in mkcramfs.c, so long as you don't mind the filesystem becoming unreadable to future kernels. +Memory Mapped cramfs image +-------------------------- + +The CRAMFS_MTD Kconfig option adds support for loading data directly from +a physical linear memory range (usually non volatile memory like Flash) +instead of going through the block device layer. This saves some memory +since no intermediate buffering is necessary to hold the data before +decompressing. + +And when data blocks are kept uncompressed and properly aligned, they will +automatically be mapped directly into user space whenever possible providing +eXecute-In-Place (XIP) from ROM of read-only segments. Data segments mapped +read-write (hence they have to be copied to RAM) may still be compressed in +the cramfs image in the same file along with non compressed read-only +segments. Both MMU and no-MMU systems are supported. This is particularly +handy for tiny embedded systems with very tight memory constraints. + +The location of the cramfs image in memory is system dependent. You must +know the proper physical address where the cramfs image is located and +configure an MTD device for it. Also, that MTD device must be supported +by a map driver that implements the "point" method. Examples of such +MTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap +(Flash device in physical memory map). MTD partitions based on such devices +are fine too. Then that device should be specified with the "mtd:" prefix +as the mount device argument. For example, to mount the MTD device named +"fs_partition" on the /mnt directory: + +$ mount -t cramfs mtd:fs_partition /mnt + +To boot a kernel with this as root filesystem, suffice to specify +something like "root=mtd:fs_partition" on the kernel command line. + + +Tools +----- + +A version of mkcramfs that can take advantage of the latest capabilities +described above can be found here: + +https://github.com/npitre/cramfs-tools + + For /usr/share/magic -------------------- diff --git a/MAINTAINERS b/MAINTAINERS index 65b0c88d5e..cd621c5f52 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3676,8 +3676,8 @@ F: drivers/cpuidle/* F: include/linux/cpuidle.h CRAMFS FILESYSTEM -W: http://sourceforge.net/projects/cramfs/ -S: Orphan / Obsolete +M: Nicolas Pitre +S: Maintained F: Documentation/filesystems/cramfs.txt F: fs/cramfs/ diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig index ef86b06bc0..f937082f32 100644 --- a/fs/cramfs/Kconfig +++ b/fs/cramfs/Kconfig @@ -1,5 +1,5 @@ config CRAMFS - tristate "Compressed ROM file system support (cramfs) (OBSOLETE)" + tristate "Compressed ROM file system support (cramfs)" select ZLIB_INFLATE help Saying Y here includes support for CramFs (Compressed ROM File @@ -15,8 +15,11 @@ config CRAMFS cramfs. Note that the root file system (the one containing the directory /) cannot be compiled as a module. - This filesystem is obsoleted by SquashFS, which is much better - in terms of performance and features. + This filesystem is limited in capabilities and performance on + purpose to remain small and low on RAM usage. It is most suitable + for small embedded systems. If you have ample RAM to spare, you may + consider a more capable compressed filesystem such as SquashFS + which is much better in terms of performance and features. If unsure, say N.