From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751425AbdHaCas (ORCPT ); Wed, 30 Aug 2017 22:30:48 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:58308 "EHLO relmlie1.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750794AbdHaCap (ORCPT ); Wed, 30 Aug 2017 22:30:45 -0400 X-IronPort-AV: E=Sophos;i="5.41,451,1498489200"; d="scan'208";a="255337111" From: Chris Brandt To: Nicolas Pitre , Alexander Viro CC: "linux-fsdevel@vger.kernel.org" , "linux-embedded@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v2 0/5] cramfs refresh for embedded usage Thread-Topic: [PATCH v2 0/5] cramfs refresh for embedded usage Thread-Index: AQHTFrYioRzOYJcEY0yQuBWeYTPtYaKd0+NA Date: Thu, 31 Aug 2017 02:30:41 +0000 Message-ID: References: <20170816173536.1879-1-nicolas.pitre@linaro.org> In-Reply-To: <20170816173536.1879-1-nicolas.pitre@linaro.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Chris.Brandt@renesas.com; x-originating-ip: [75.60.247.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;SG2PR06MB0933;20:zqZf2gnIAG4RMoah5jkJo2vqDxMRD+urqmTsit2PXyTUwSyc4CaSB4DmmRqaN59i/4Bri+pbPc+AinavYL0wI8okXIr8SdLNiEhPOmZszalw+8aH7hyGhGwPLUS8+TXHNb1BQq3S6c6Pr67HRXiTzXex6QB92rP0CKo00srfGwc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3abc9425-7129-4f8d-6916-08d4f0184668 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:SG2PR06MB0933; x-ms-traffictypediagnostic: SG2PR06MB0933: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SG2PR06MB0933;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SG2PR06MB0933; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(199003)(189002)(24454002)(229853002)(33656002)(4326008)(5250100002)(25786009)(105586002)(106356001)(5660300001)(66066001)(86362001)(97736004)(2906002)(6306002)(54906002)(8936002)(74316002)(6246003)(9686003)(50986999)(966005)(2950100002)(3280700002)(54356999)(81166006)(99286003)(81156014)(76176999)(101416001)(72206003)(7736002)(53936002)(14454004)(305945005)(102836003)(478600001)(189998001)(55016002)(8676002)(6116002)(6506006)(3846002)(7696004)(6436002)(3660700001)(68736007)(2900100001)(562404015);DIR:OUT;SFP:1102;SCL:1;SRVR:SG2PR06MB0933;H:SG2PR06MB1165.apcprd06.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2017 02:30:41.6586 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB0933 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v7V2UrVB023614 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