From patchwork Tue Sep 4 11:48:26 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shmulik Ladkani X-Patchwork-Id: 181545 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (unknown [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id AB4EB2C0094 for ; Tue, 4 Sep 2012 21:50:01 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1T8rce-0003oA-SF; Tue, 04 Sep 2012 11:48:48 +0000 Received: from mail-wi0-f169.google.com ([209.85.212.169]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1T8rcb-0003nw-NN for linux-mtd@lists.infradead.org; Tue, 04 Sep 2012 11:48:46 +0000 Received: by wibhm2 with SMTP id hm2so3798399wib.0 for ; Tue, 04 Sep 2012 04:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=npSk1yutk0joQXEoL+1RhTsp5hLK6+iPnDpyBRWF3r0=; b=oO752p61kG+p/1xLGOH+zWnVa4LtOVWL+IAov1daMLDFNrcczWXZg5V8+x//0KA/Pu Gh6r9Loj2PX1NY1/w2GA6jQCJnhz/wBWnfl3rUMHsqGhr871QvY7lYOHQtYu4Yxl7r0i q43tVH7VK2QdL1JMfeuIllPkJD3j7Bt5d4Mlr29Exp6mAxcsmgIWz0XG4uPxfbAWdVQK axxgtCld/Ain6VMiP54Ddnu6bJF3mvft4KZpjbSLpe+jx+f7ijHSy44j18LSI1WGI7pB ESja9DSCBHnY8CsYYmbr+mj5aTrDWndeBVeGHVaSwt0U7R1j8ZPuPoC5QiVKvLWC0Xot X1/g== Received: by 10.216.132.135 with SMTP id o7mr10772416wei.6.1346759322972; Tue, 04 Sep 2012 04:48:42 -0700 (PDT) Received: from halley (93-172-133-35.bb.netvision.net.il. [93.172.133.35]) by mx.google.com with ESMTPS id q4sm24075405wix.9.2012.09.04.04.48.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 04:48:42 -0700 (PDT) Date: Tue, 4 Sep 2012 14:48:26 +0300 From: Shmulik Ladkani To: dedekind1@gmail.com Subject: Re: [PATCH 1/3] mtd: cmdlinepart: make the partitions rule more strict Message-ID: <20120904144826.7b9b7518@halley> In-Reply-To: <1346686544.3061.75.camel@sauron.fi.intel.com> References: <1346001700-26895-1-git-send-email-shijie8@gmail.com> <1346656701.3061.8.camel@sauron.fi.intel.com> <1346686544.3061.75.camel@sauron.fi.intel.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu) Mime-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.169 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (shmulik.ladkani[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: linux-mtd@lists.infradead.org, Huang Shijie X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Mon, 03 Sep 2012 18:35:44 +0300 Artem Bityutskiy wrote: > With the logic I suggested, for this case what I said would basically: > > 1. Sort. This leads to > > 100m@100m(kernel) > 1g@200m(rootfs) > 100m(boot) > > "OFFSET_CONTINOUS" is always the largest and will be at the end when > sorting. > > 2. Verification. > > We verify for overlaps and gaps. And refuse this one. Artem, Huang, Sorry for the long delay, got busy with urgent matters (found out I need to go thru some surgery), I will probably not be available in the upcoming days, but I've read the correspondance and wanted to share my two cents... My POV is that sorting and verification is not needed, is troublesome, and might affect users in ways they don't expect. So far, mtdparts commandline parsing has been very lenient and liberal. I think we should keep this approach; give the user the flexibility, he'll be responsible to provide meaningful cmdline parts for his system. Actually, Huang's initial complaint was that 'parse_cmdline_partitions' was too strict - the truncated partition was not registered! Now, philosophy aside, let's talk about some usecases that might break. I remember overlapping partitions (more precisely, partition that is a subset of another) being common in some embedded systems, where the "rootfs" and "kernel" partitions are a subset of the "overall image" partition. Why break this? if users enjoy the flexibility, and careful not to create silly partitions, I'm in favor of keeping the flexibility. Same goes for sorting. If one has a system hacked to work with mtd0 hardcodedly, but mtd0's physical location is somewhere at the end of the device, why reorder the partitions enumeration affecting this system? I'd say keep it simple and flexible. I trust the user to provide meaningful partitions in the cmdline. Anyways, please consider this approach. My patch suggestion might look as (and might need some rework): Regards, Shmulik diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/cmdlinepart.c index 17b0bd4..f5df613 100644 --- a/drivers/mtd/cmdlinepart.c +++ b/drivers/mtd/cmdlinepart.c @@ -324,7 +324,6 @@ static int parse_cmdline_partitions(struct mtd_info *master, "%s: partitioning exceeds flash size, truncating\n", part->mtd_id); part->parts[i].size = master->size - offset; - part->num_parts = i; } offset += part->parts[i].size; }