From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E14FC4332F for ; Thu, 17 Nov 2022 00:19:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234156AbiKQATo (ORCPT ); Wed, 16 Nov 2022 19:19:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230103AbiKQATk (ORCPT ); Wed, 16 Nov 2022 19:19:40 -0500 Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B582547328; Wed, 16 Nov 2022 16:19:37 -0800 (PST) Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.94.2) (envelope-from ) id 1ovScc-0002P6-CE; Thu, 17 Nov 2022 01:19:14 +0100 Date: Thu, 17 Nov 2022 00:19:10 +0000 From: Daniel Golle To: Christoph Hellwig Cc: Jens Axboe , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Matthew Wilcox , "Martin K. Petersen" , Chaitanya Kulkarni , Michal Orzel , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [PATCH v5 3/4] partitions/efi: add support for uImage.FIT sub-partitions Message-ID: References: <7526fc5a461a0d68eb1dab575f9c1950638fc21a.1668548123.git.daniel@makrotopia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, On Tue, Nov 15, 2022 at 10:01:05PM -0800, Christoph Hellwig wrote: > On Tue, Nov 15, 2022 at 09:47:06PM +0000, Daniel Golle wrote: > > Add new GUID allowing to parse uImage.FIT stored in a GPT partition > > and map filesystem sub-image as sub-partitions. > > NAK, we should not go out from the partition code to parse random > weird image formats. While weirdness is certainly subjective, uImage.FIT is not just a random image format but used by a great majority of headless embedded Linux devices out there. It's the default image format of many of the SDKs distributed by chip vendors such as Allwinner, Marvell, MediaTek, NXP, Qualcomm/Atheros, ... Having better support for it in Linux hence doesn't seem too far-fetched to me, especially given that we got partition parsers for all sorts of historic (Acorn, Amiga, Atari, ...) or actually exotic (Karma?) formats. Even Microsoft Windows' Logical Disk Manager is supported natively by the kernel... > If you want to support uImage.FIT just write a tiny stackable block > driver or dm table for it. As this is used on rather tiny embedded devices my hope was to keep things simple and not having to enable device mapper on systems which have anyway only very small amounts of storage and won't ever need most of the device mapper features. Using a tiny block driver instead is an option, I've implemented this approach in the past couple of hours and it works just as fine. In this case I would introduce a new kernel cmdline option allowing to specify which block device (ie. a partition on eMMC, or mtdblock or ubiblock device) to launch the uImage.FIT parser on. Allowing this new driver to add block partitions by exporting a new helper functions for that in block/partition/core.c would greatly simplify things, as then the existing partitioning code could still be used (instead of basically having to re-implement loopdev and introduce a whole new type of block devices). I will post an RFC series illustrating this approach. Please let me know if this sounds acceptable, so I won't put effort into implementing something which will then be rejected again after 5 iterations on the mailing list for reasons which could have been expressed from the beginning. An RFC for this series was posted on 2022-04-25 [1], I wouldn't have worked months to fix all requests of other maintainers and tested it on a variety of different hardware knowing that the whole approach will be NACK'ed... And, of course, thank you anyway for reviewing! Cheers Daniel [1]: https://patchwork.kernel.org/project/linux-block/list/?series=635369&state=*