From: Brian Norris <computersforpeace@gmail.com> To: Caizhiyong <caizhiyong@huawei.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Karel Zak <kzak@redhat.com>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Wanglin (Albert)" <albert.wanglin@huawei.com>, Artem Bityutskiy <dedekind1@gmail.com>, Shmulik Ladkani <shmulik.ladkani@gmail.com>, Huang Shijie <b32955@freescale.com> Subject: Re: [PATCH] block: add command line partition parser Date: Thu, 15 Aug 2013 00:09:38 -0700 [thread overview] Message-ID: <20130815070938.GB24007@brian-ubuntu> (raw) In-Reply-To: <C3050A4DBA34F345975765E43127F10F1C064357@szxeml512-mbx.china.huawei.com> On Thu, Aug 15, 2013 at 06:16:04AM +0000, Caizhiyong wrote: > > -----Original Message----- > > From: Brian Norris [mailto:computersforpeace@gmail.com] > > Sent: Thursday, August 15, 2013 1:00 PM > > To: Caizhiyong > > Cc: Andrew Morton; Karel Zak; linux-mtd@lists.infradead.org; > > linux-kernel@vger.kernel.org; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani; > > Huang Shijie > > Subject: Re: [PATCH] block: add command line partition parser > > > > On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote: > > > > -----Original Message----- > > > > From: Brian Norris [mailto:computersforpeace@gmail.com] > > > > Sent: Thursday, August 15, 2013 8:12 AM > > > > To: Andrew Morton > > > > Cc: Caizhiyong; Karel Zak; linux-mtd@lists.infradead.org; > > > > linux-kernel@vger.kernel.org; Wanglin (Albert); Artem Bityutskiy; Shmulik > > Ladkani; > > > > Huang Shijie > > > > Subject: Re: [PATCH] block: add command line partition parser > > > > > > > > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton > > > > <akpm@linux-foundation.org> wrote: > > > > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <caizhiyong@huawei.com> wrote: > > > > > > > > > >> move the command line parser to a separate module, and change it into > > > > >> library-style code. > > > > >> > > > > >> reference: https://lkml.org/lkml/2013/8/6/550 > > > > > > > > The most recent patch is an addendum to this linked patch then? > > > > > > > > > Well OK. But to prove the library's usefulness and to generally clean > > > > > up the kernel, someone needs to sign up to the task of converting > > > > > drivers/mtd/cmdlinepart.c to use this code. > > > > > > > > > > I've been hopefully cc'ing various MTD people but am not being > > > > > overwhelmed with waves of enthusiasm ;) > > > > > > > > "I've been" implies that you have done so prior to this email. And > > > > "people" implies more than one person. I see that you CC'd David > > > > Woodhouse over a week ago, but he's fairly silent these days on MTD > > > > things. It's Artem or me who handle most of the day-to-day of MTD. And > > > > this is the first time I've seen this! (BTW, please include > > > > linux-mtd@lists.infradead.org for anything involving MTD.) > > > > > > > > This seems reasonable, and I'd be willing to work with this proposal. > > > > > > > > Caizhiyong, can you submit a clear single patch (or series of > > > > patches), CC'd to linux-mtd at least? Then we can see about supporting > > > > it in MTD. It doesn't look too difficult, but I need to check that it > > > > faithfully mimics the capability we currently rely on. There have been > > > > previous discussions on changing it, but this was rejected in favor of > > > > allowing more flexibility. Here's part of one such conversation: > > > > > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html > > > > > > > > So I would recommend: > > > > (1) consider carefully the implications of your command-line format > > > > now, rather than later > > > > (2) if you want MTD to use it, it needs to support the features we use now > > > > > > It is fully functional reference MTD, :-). > > > > I realize that. I just want to be clear that we have to reconcile (1) > > and (2). IOW, if block device requirements stray too far from MTD > > requirements, then we might as well drop the idea of integration now. > > But if they agree, then we can move forward. > > > > > > Some particular cases to consider: overlapping partitions (how do > > > > block devices handle overlapping partitions?), out-of-order > > > > specification, zero sized partitions, mixed syntax (some specified > > > > with an offset, some not), multiple '-' partitions. > > > > > > I think the 'offset' just is used to hide some MTD space. > > > > No, it specifies offset as a distance from the beginning of the flash, > > so partitions can be numbered out of order. This is intentionally > > utilized by some users, for example, to ensure that a particular > > partition is always /dev/mtd0, even if it is not the first partition > > physically. > > > > > There are two way: > > > 1) redefine the 'offset' as a gap between forward partition and next partition. > > > 2) add code forbid command line partitions overlapping and out-of-order. > > > > > > I recommend 1), it seems to solve those problem(overlapping and out-of-order), > > but it will affect habit. > > > > The linked discussion is where MTD settled on retaining old practice. I > > brought it up not so that we change it here, but so that you would > > understand what you are agreeing to if you adopt a common MTD and block > > device parsing infrastructure. > > > > [Note that I am much less familiar with block device mechanics than with > > MTD.] Are any of the problem areas I mentioned actually forbidden on > > block devices? I know, for instance, that an MBR partition table can > > specify partitions out of order. And I've googled around and seen some > > posts about people (unintentionally) ending up with overlapping hard > > disk partitions. > > > > So from my primitive knowledge, it sounds like a block devices parser > > could agree with the same principle put forward by Shmulik in that > > second URL: > > > > "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." > > > > Brian > > I want to use the MTD command line partition method on block devices (eMMC). > It is very suitable for embedded systems. I think, in embedded system partition method, > if somebody need some feature on MTD device, he may be also need it on block device. > so I fully functional reference MTD command line partition. I agree. I'm curious: have you seen any need for a similar arrangement via device-tree? See, for example, drivers/mtd/ofpart.c. > I tested the out-of-order and overlapping on my system, used command line partition, It is work ok. > The block device code is not make any restrictions on partition out-of-order and overlapping. OK, good. Thanks for checking. > I hope extend the flexibility to block device. Sure. I'll try to review the full patch soon and test out integrating it with MTD. Thanks, Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace@gmail.com> To: Caizhiyong <caizhiyong@huawei.com> Cc: "Wanglin \(Albert\)" <albert.wanglin@huawei.com>, Artem Bityutskiy <dedekind1@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Huang Shijie <b32955@freescale.com>, Karel Zak <kzak@redhat.com>, "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>, Shmulik Ladkani <shmulik.ladkani@gmail.com>, Andrew Morton <akpm@linux-foundation.org> Subject: Re: [PATCH] block: add command line partition parser Date: Thu, 15 Aug 2013 00:09:38 -0700 [thread overview] Message-ID: <20130815070938.GB24007@brian-ubuntu> (raw) In-Reply-To: <C3050A4DBA34F345975765E43127F10F1C064357@szxeml512-mbx.china.huawei.com> On Thu, Aug 15, 2013 at 06:16:04AM +0000, Caizhiyong wrote: > > -----Original Message----- > > From: Brian Norris [mailto:computersforpeace@gmail.com] > > Sent: Thursday, August 15, 2013 1:00 PM > > To: Caizhiyong > > Cc: Andrew Morton; Karel Zak; linux-mtd@lists.infradead.org; > > linux-kernel@vger.kernel.org; Wanglin (Albert); Artem Bityutskiy; Shmulik Ladkani; > > Huang Shijie > > Subject: Re: [PATCH] block: add command line partition parser > > > > On Thu, Aug 15, 2013 at 03:38:47AM +0000, Caizhiyong wrote: > > > > -----Original Message----- > > > > From: Brian Norris [mailto:computersforpeace@gmail.com] > > > > Sent: Thursday, August 15, 2013 8:12 AM > > > > To: Andrew Morton > > > > Cc: Caizhiyong; Karel Zak; linux-mtd@lists.infradead.org; > > > > linux-kernel@vger.kernel.org; Wanglin (Albert); Artem Bityutskiy; Shmulik > > Ladkani; > > > > Huang Shijie > > > > Subject: Re: [PATCH] block: add command line partition parser > > > > > > > > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton > > > > <akpm@linux-foundation.org> wrote: > > > > > On Tue, 13 Aug 2013 06:02:17 +0000 Caizhiyong <caizhiyong@huawei.com> wrote: > > > > > > > > > >> move the command line parser to a separate module, and change it into > > > > >> library-style code. > > > > >> > > > > >> reference: https://lkml.org/lkml/2013/8/6/550 > > > > > > > > The most recent patch is an addendum to this linked patch then? > > > > > > > > > Well OK. But to prove the library's usefulness and to generally clean > > > > > up the kernel, someone needs to sign up to the task of converting > > > > > drivers/mtd/cmdlinepart.c to use this code. > > > > > > > > > > I've been hopefully cc'ing various MTD people but am not being > > > > > overwhelmed with waves of enthusiasm ;) > > > > > > > > "I've been" implies that you have done so prior to this email. And > > > > "people" implies more than one person. I see that you CC'd David > > > > Woodhouse over a week ago, but he's fairly silent these days on MTD > > > > things. It's Artem or me who handle most of the day-to-day of MTD. And > > > > this is the first time I've seen this! (BTW, please include > > > > linux-mtd@lists.infradead.org for anything involving MTD.) > > > > > > > > This seems reasonable, and I'd be willing to work with this proposal. > > > > > > > > Caizhiyong, can you submit a clear single patch (or series of > > > > patches), CC'd to linux-mtd at least? Then we can see about supporting > > > > it in MTD. It doesn't look too difficult, but I need to check that it > > > > faithfully mimics the capability we currently rely on. There have been > > > > previous discussions on changing it, but this was rejected in favor of > > > > allowing more flexibility. Here's part of one such conversation: > > > > > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-August/043599.html > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-September/043825.html > > > > http://lists.infradead.org/pipermail/linux-mtd/2012-December/045322.html > > > > > > > > So I would recommend: > > > > (1) consider carefully the implications of your command-line format > > > > now, rather than later > > > > (2) if you want MTD to use it, it needs to support the features we use now > > > > > > It is fully functional reference MTD, :-). > > > > I realize that. I just want to be clear that we have to reconcile (1) > > and (2). IOW, if block device requirements stray too far from MTD > > requirements, then we might as well drop the idea of integration now. > > But if they agree, then we can move forward. > > > > > > Some particular cases to consider: overlapping partitions (how do > > > > block devices handle overlapping partitions?), out-of-order > > > > specification, zero sized partitions, mixed syntax (some specified > > > > with an offset, some not), multiple '-' partitions. > > > > > > I think the 'offset' just is used to hide some MTD space. > > > > No, it specifies offset as a distance from the beginning of the flash, > > so partitions can be numbered out of order. This is intentionally > > utilized by some users, for example, to ensure that a particular > > partition is always /dev/mtd0, even if it is not the first partition > > physically. > > > > > There are two way: > > > 1) redefine the 'offset' as a gap between forward partition and next partition. > > > 2) add code forbid command line partitions overlapping and out-of-order. > > > > > > I recommend 1), it seems to solve those problem(overlapping and out-of-order), > > but it will affect habit. > > > > The linked discussion is where MTD settled on retaining old practice. I > > brought it up not so that we change it here, but so that you would > > understand what you are agreeing to if you adopt a common MTD and block > > device parsing infrastructure. > > > > [Note that I am much less familiar with block device mechanics than with > > MTD.] Are any of the problem areas I mentioned actually forbidden on > > block devices? I know, for instance, that an MBR partition table can > > specify partitions out of order. And I've googled around and seen some > > posts about people (unintentionally) ending up with overlapping hard > > disk partitions. > > > > So from my primitive knowledge, it sounds like a block devices parser > > could agree with the same principle put forward by Shmulik in that > > second URL: > > > > "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." > > > > Brian > > I want to use the MTD command line partition method on block devices (eMMC). > It is very suitable for embedded systems. I think, in embedded system partition method, > if somebody need some feature on MTD device, he may be also need it on block device. > so I fully functional reference MTD command line partition. I agree. I'm curious: have you seen any need for a similar arrangement via device-tree? See, for example, drivers/mtd/ofpart.c. > I tested the out-of-order and overlapping on my system, used command line partition, It is work ok. > The block device code is not make any restrictions on partition out-of-order and overlapping. OK, good. Thanks for checking. > I hope extend the flexibility to block device. Sure. I'll try to review the full patch soon and test out integrating it with MTD. Thanks, Brian
next prev parent reply other threads:[~2013-08-15 7:09 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-03 9:57 [PATCH] block: support embedded device command line partition Caizhiyong 2013-08-05 22:22 ` Andrew Morton 2013-08-06 10:53 ` Caizhiyong 2013-08-07 0:10 ` Andrew Morton 2013-08-13 6:02 ` [PATCH] block: add command line partition parser Caizhiyong 2013-08-14 22:57 ` Andrew Morton 2013-08-14 22:57 ` Andrew Morton 2013-08-15 0:11 ` Brian Norris 2013-08-15 0:11 ` Brian Norris 2013-08-15 0:30 ` Andrew Morton 2013-08-15 0:30 ` Andrew Morton 2013-08-15 3:38 ` Caizhiyong 2013-08-15 3:38 ` Caizhiyong 2013-08-15 5:00 ` Brian Norris 2013-08-15 5:00 ` Brian Norris 2013-08-15 6:16 ` Caizhiyong 2013-08-15 6:16 ` Caizhiyong 2013-08-15 7:09 ` Brian Norris [this message] 2013-08-15 7:09 ` Brian Norris 2013-08-15 7:45 ` Caizhiyong 2013-08-15 7:45 ` Caizhiyong 2013-08-15 8:32 ` Brian Norris 2013-08-15 8:32 ` Brian Norris 2013-08-15 15:52 ` [PATCH] block: support embedded device command line partition Stephen Warren 2013-08-16 2:54 ` Caizhiyong 2013-08-16 16:02 ` Stephen Warren 2013-08-19 8:36 ` Caizhiyong 2013-08-19 16:05 ` Stephen Warren 2013-09-17 11:15 ` Linus Walleij 2013-09-17 13:08 ` Caizhiyong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130815070938.GB24007@brian-ubuntu \ --to=computersforpeace@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=albert.wanglin@huawei.com \ --cc=b32955@freescale.com \ --cc=caizhiyong@huawei.com \ --cc=dedekind1@gmail.com \ --cc=kzak@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=shmulik.ladkani@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.