Re: [PATCH] block: add command line partition parser
On 08/15/2013 12:45 AM, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] ... On Thu, Aug 15, 2013 at 06:16:04AM +, Caizhiyong wrote: 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. So far, I have no seen. We mainly use ARM. For ARM, device-tree is a new thing. But device-tree is *the* thing for ARM going forward, and the kernel command line can get unwieldy (and beyond its limits) pretty quickly like this. 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. If there is no problem, I will send my next patch, mtd cmdline parts use cmdline-parser lib. We will get some reviews on this soon (no time for me tonight). Do you already have a mtd patch? If so, you might as well post it for review as well. Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] block: add command line partition parser
> -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: Thursday, August 15, 2013 3:10 PM > To: Caizhiyong > Cc: Andrew Morton; Karel Zak; linux-...@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 06:16:04AM +, Caizhiyong wrote: > > > -Original Message- > > > From: Brian Norris [mailto:computersforpe...@gmail.com] > > > Sent: Thursday, August 15, 2013 1:00 PM > > > To: Caizhiyong > > > Cc: Andrew Morton; Karel Zak; linux-...@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 +, Caizhiyong wrote: > > > > > -Original Message- > > > > > From: Brian Norris [mailto:computersforpe...@gmail.com] > > > > > Sent: Thursday, August 15, 2013 8:12 AM > > > > > To: Andrew Morton > > > > > Cc: Caizhiyong; Karel Zak; linux-...@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 > > > > > wrote: > > > > > > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong > > > > > > > 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-...@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 rec
Re: [PATCH] block: add command line partition parser
On Thu, Aug 15, 2013 at 06:16:04AM +, Caizhiyong wrote: > > -Original Message- > > From: Brian Norris [mailto:computersforpe...@gmail.com] > > Sent: Thursday, August 15, 2013 1:00 PM > > To: Caizhiyong > > Cc: Andrew Morton; Karel Zak; linux-...@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 +, Caizhiyong wrote: > > > > -Original Message- > > > > From: Brian Norris [mailto:computersforpe...@gmail.com] > > > > Sent: Thursday, August 15, 2013 8:12 AM > > > > To: Andrew Morton > > > > Cc: Caizhiyong; Karel Zak; linux-...@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 > > > > wrote: > > > > > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong > > > > > 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-...@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 > > utiliz
RE: [PATCH] block: add command line partition parser
> -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: Thursday, August 15, 2013 1:00 PM > To: Caizhiyong > Cc: Andrew Morton; Karel Zak; linux-...@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 +, Caizhiyong wrote: > > > -Original Message- > > > From: Brian Norris [mailto:computersforpe...@gmail.com] > > > Sent: Thursday, August 15, 2013 8:12 AM > > > To: Andrew Morton > > > Cc: Caizhiyong; Karel Zak; linux-...@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 > > > wrote: > > > > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong > > > > 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-...@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. >
RE: [PATCH] block: add command line partition parser
-Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 1:00 PM To: Caizhiyong Cc: Andrew Morton; Karel Zak; linux-...@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 +, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 8:12 AM To: Andrew Morton Cc: Caizhiyong; Karel Zak; linux-...@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 a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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-...@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
Re: [PATCH] block: add command line partition parser
On Thu, Aug 15, 2013 at 06:16:04AM +, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 1:00 PM To: Caizhiyong Cc: Andrew Morton; Karel Zak; linux-...@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 +, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 8:12 AM To: Andrew Morton Cc: Caizhiyong; Karel Zak; linux-...@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 a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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-...@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
RE: [PATCH] block: add command line partition parser
-Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 3:10 PM To: Caizhiyong Cc: Andrew Morton; Karel Zak; linux-...@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 06:16:04AM +, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 1:00 PM To: Caizhiyong Cc: Andrew Morton; Karel Zak; linux-...@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 +, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 8:12 AM To: Andrew Morton Cc: Caizhiyong; Karel Zak; linux-...@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 a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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-...@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
Re: [PATCH] block: add command line partition parser
On 08/15/2013 12:45 AM, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] ... On Thu, Aug 15, 2013 at 06:16:04AM +, Caizhiyong wrote: 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. So far, I have no seen. We mainly use ARM. For ARM, device-tree is a new thing. But device-tree is *the* thing for ARM going forward, and the kernel command line can get unwieldy (and beyond its limits) pretty quickly like this. 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. If there is no problem, I will send my next patch, mtd cmdline parts use cmdline-parser lib. We will get some reviews on this soon (no time for me tonight). Do you already have a mtd patch? If so, you might as well post it for review as well. Thanks, Brian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Thu, Aug 15, 2013 at 03:38:47AM +, Caizhiyong wrote: > > -Original Message- > > From: Brian Norris [mailto:computersforpe...@gmail.com] > > Sent: Thursday, August 15, 2013 8:12 AM > > To: Andrew Morton > > Cc: Caizhiyong; Karel Zak; linux-...@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 > > wrote: > > > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong > > > 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-...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] block: add command line partition parser
> -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: Thursday, August 15, 2013 8:12 AM > To: Andrew Morton > Cc: Caizhiyong; Karel Zak; linux-...@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 > wrote: > > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong 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-...@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, :-). > > 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. 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. > > Anyway, if you resend, we can review. > > Thanks, > Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Wed, 14 Aug 2013 17:11:51 -0700 Brian Norris wrote: > On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton > wrote: > > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong 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? The unifed latest version is appended. > > 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-...@lists.infradead.org for anything involving MTD.) > > This seems reasonable, and I'd be willing to work with this proposal. Thanks. > 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 > > 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. This patch is still at the review-and-under-test stage so now is a fine time to make changes. > Anyway, if you resend, we can review. From: Cai Zhiyong Subject: block: support embedded device command line partition Read block device partition table from command line. The partition used for fixed block device (eMMC) embedded device. It is no MBR, save storage space. Bootloader can be easily accessed by absolute address of data on the block device. Users can easily change the partition. This code reference MTD partition, source "drivers/mtd/cmdlinepart.c" About the partition verbose reference "Documentation/block/cmdline-partition.txt" [a...@linux-foundation.org: fix printk text] Signed-off-by: Cai Zhiyong Cc: Karel Zak Cc: "Wanglin (Albert)" Cc: Marius Groeger Cc: David Woodhouse Cc: Jens Axboe Cc: Brian Norris Cc: Artem Bityutskiy Signed-off-by: Andrew Morton --- Documentation/block/cmdline-partition.txt | 40 +++ block/Kconfig |6 block/Makefile|1 block/cmdline-parser.c| 249 block/partitions/Kconfig |7 block/partitions/Makefile |1 block/partitions/check.c |4 block/partitions/cmdline.c| 99 +++ block/partitions/cmdline.h|2 include/linux/cmdline-parser.h| 43 +++ 10 files changed, 452 insertions(+) diff -puN /dev/null Documentation/block/cmdline-partition.txt --- /dev/null +++ a/Documentation/block/cmdline-partition.txt @@ -0,0 +1,40 @@ +Embedded device command line partition += + +Read block device partition table from command line. +The partition used for fixed block device (eMMC) embedded device. +It is no MBR, save storage space. Bootloader can be easily accessed +by absolute address of data on the block device. +Users can easily change the partition. + +The format for the command line is just like mtdparts: + +blkdevparts=[;] + := :[,] + := [@](part-name) + + +block device disk name, embedded device used fixed block device, +it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0. + + +partition size, in bytes, such as: 512, 1m, 1G. + + +partition start address, in bytes. + +(part-name) +partition name, kernel send uevent with "PARTNAME". application can create +a link to block device partition with the name "PARTNAME". +user space application can access partition by partition name. + +Example: +eMMC disk name is "mmcblk0" and
Re: [PATCH] block: add command line partition parser
On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton wrote: > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong 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-...@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 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. Anyway, if you resend, we can review. Thanks, Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Tue, 13 Aug 2013 06:02:17 + Caizhiyong 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 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 ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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 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 ;) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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-...@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 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. Anyway, if you resend, we can review. Thanks, Brian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Wed, 14 Aug 2013 17:11:51 -0700 Brian Norris computersforpe...@gmail.com wrote: On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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? The unifed latest version is appended. 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-...@lists.infradead.org for anything involving MTD.) This seems reasonable, and I'd be willing to work with this proposal. Thanks. 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 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. This patch is still at the review-and-under-test stage so now is a fine time to make changes. Anyway, if you resend, we can review. From: Cai Zhiyong caizhiy...@huawei.com Subject: block: support embedded device command line partition Read block device partition table from command line. The partition used for fixed block device (eMMC) embedded device. It is no MBR, save storage space. Bootloader can be easily accessed by absolute address of data on the block device. Users can easily change the partition. This code reference MTD partition, source drivers/mtd/cmdlinepart.c About the partition verbose reference Documentation/block/cmdline-partition.txt [a...@linux-foundation.org: fix printk text] Signed-off-by: Cai Zhiyong caizhiy...@huawei.com Cc: Karel Zak k...@redhat.com Cc: Wanglin (Albert) albert.wang...@huawei.com Cc: Marius Groeger m...@sysgo.de Cc: David Woodhouse dw...@infradead.org Cc: Jens Axboe ax...@kernel.dk Cc: Brian Norris computersforpe...@gmail.com Cc: Artem Bityutskiy dedek...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- Documentation/block/cmdline-partition.txt | 40 +++ block/Kconfig |6 block/Makefile|1 block/cmdline-parser.c| 249 block/partitions/Kconfig |7 block/partitions/Makefile |1 block/partitions/check.c |4 block/partitions/cmdline.c| 99 +++ block/partitions/cmdline.h|2 include/linux/cmdline-parser.h| 43 +++ 10 files changed, 452 insertions(+) diff -puN /dev/null Documentation/block/cmdline-partition.txt --- /dev/null +++ a/Documentation/block/cmdline-partition.txt @@ -0,0 +1,40 @@ +Embedded device command line partition += + +Read block device partition table from command line. +The partition used for fixed block device (eMMC) embedded device. +It is no MBR, save storage space. Bootloader can be easily accessed +by absolute address of data on the block device. +Users can easily change the partition. + +The format for the command line is just like mtdparts: + +blkdevparts=blkdev-def[;blkdev-def] + blkdev-def := blkdev-id:partdef[,partdef] +partdef := size[@offset](part-name) + +blkdev-id +block device disk name, embedded device used fixed block device, +it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0. + +size +partition size, in bytes, such as: 512, 1m, 1G. + +offset +partition start
RE: [PATCH] block: add command line partition parser
-Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 8:12 AM To: Andrew Morton Cc: Caizhiyong; Karel Zak; linux-...@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 a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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-...@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, :-). 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. 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. Anyway, if you resend, we can review. Thanks, Brian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: add command line partition parser
On Thu, Aug 15, 2013 at 03:38:47AM +, Caizhiyong wrote: -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Thursday, August 15, 2013 8:12 AM To: Andrew Morton Cc: Caizhiyong; Karel Zak; linux-...@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 a...@linux-foundation.org wrote: On Tue, 13 Aug 2013 06:02:17 + Caizhiyong caizhiy...@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-...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: add command line partition parser
From: Cai Zhiyong
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
Signed-off-by: Cai Zhiyong
---
block/Kconfig | 6 +
block/Makefile | 1 +
block/cmdline-parser.c | 249 +
block/partitions/Kconfig | 1 +
block/partitions/cmdline.c | 311 ++---
include/linux/cmdline-parser.h | 43 ++
6 files changed, 342 insertions(+), 269 deletions(-)
create mode 100644 block/cmdline-parser.c
create mode 100644 include/linux/cmdline-parser.h
diff --git a/block/Kconfig b/block/Kconfig
index a7e40a7..7f38e40 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -99,6 +99,12 @@ config BLK_DEV_THROTTLING
See Documentation/cgroups/blkio-controller.txt for more information.
+config CMDLINE_PARSER
+ bool "Block device command line partition parser"
+ default n
+ ---help---
+ Parsing command line, get the partitions information.
+
menu "Partition Types"
source "block/partitions/Kconfig"
diff --git a/block/Makefile b/block/Makefile
index 39b76ba..4fa4be5 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched.o
obj-$(CONFIG_BLOCK_COMPAT) += compat_ioctl.o
obj-$(CONFIG_BLK_DEV_INTEGRITY)+= blk-integrity.o
+obj-$(CONFIG_CMDLINE_PARSER) += cmdline-parser.o
diff --git a/block/cmdline-parser.c b/block/cmdline-parser.c
new file mode 100644
index 000..18fb435
--- /dev/null
+++ b/block/cmdline-parser.c
@@ -0,0 +1,249 @@
+/*
+ * Parse command line, get partition information
+ *
+ * Written by Cai Zhiyong
+ *
+ */
+#include
+#include
+#include
+
+static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
+{
+ int ret = 0;
+ struct cmdline_subpart *new_subpart;
+
+ *subpart = NULL;
+
+ new_subpart = kzalloc(sizeof(struct cmdline_subpart), GFP_KERNEL);
+ if (!new_subpart)
+ return -ENOMEM;
+
+ if (*partdef == '-') {
+ new_subpart->size = (sector_t)(~0ULL);
+ partdef++;
+ } else {
+ new_subpart->size = (sector_t)memparse(partdef, );
+ if (new_subpart->size < (sector_t)PAGE_SIZE) {
+ pr_warn("cmdline partition size is invalid.");
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ if (*partdef == '@') {
+ partdef++;
+ new_subpart->from = (sector_t)memparse(partdef, );
+ } else {
+ new_subpart->from = (sector_t)(~0ULL);
+ }
+
+ if (*partdef == '(') {
+ int length;
+ char *next = strchr(++partdef, ')');
+
+ if (!next) {
+ pr_warn("cmdline partition format is invalid.");
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ length = min_t(int, next - partdef,
+ sizeof(new_subpart->name) - 1);
+ strncpy(new_subpart->name, partdef, length);
+ new_subpart->name[length] = '\0';
+
+ partdef = ++next;
+ } else
+ new_subpart->name[0] = '\0';
+
+ new_subpart->flags = 0;
+
+ if (!strncmp(partdef, "ro", 2)) {
+ new_subpart->flags |= PF_RDONLY;
+ partdef += 2;
+ }
+
+ if (!strncmp(partdef, "lk", 2)) {
+ new_subpart->flags |= PF_POWERUP_LOCK;
+ partdef += 2;
+ }
+
+ *subpart = new_subpart;
+ return 0;
+fail:
+ kfree(new_subpart);
+ return ret;
+}
+
+static void free_subpart(struct cmdline_parts *parts)
+{
+ struct cmdline_subpart *subpart;
+
+ while (parts->subpart) {
+ subpart = parts->subpart;
+ parts->subpart = subpart->next_subpart;
+ kfree(subpart);
+ }
+}
+
+static int parse_parts(struct cmdline_parts **parts, const char *bdevdef)
+{
+ int ret = -EINVAL;
+ char *next;
+ int length;
+ struct cmdline_subpart **next_subpart;
+ struct cmdline_parts *newparts;
+ char buf[BDEVNAME_SIZE + 32 + 4];
+
+ *parts = NULL;
+
+ newparts = kzalloc(sizeof(struct cmdline_parts), GFP_KERNEL);
+ if (!newparts)
+ return -ENOMEM;
+
+ next = strchr(bdevdef, ':');
+ if (!next) {
+ pr_warn("cmdline partition has no block device.");
+ goto fail;
+ }
+
+ length = min_t(int, next - bdevdef, sizeof(newparts->name) - 1);
+ strncpy(newparts->name, bdevdef, length);
+ newparts->name[length] = '\0';
+ newparts->nr_subparts = 0;
+
+ next_subpart = >subpart;
+
+ while (next && *(++next)) {
+ bdevdef = next;
+ next = strchr(bdevdef, ',');
[PATCH] block: add command line partition parser
From: Cai Zhiyong caizhiy...@huawei.com
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
Signed-off-by: Cai Zhiyong caizhiy...@huawei.com
---
block/Kconfig | 6 +
block/Makefile | 1 +
block/cmdline-parser.c | 249 +
block/partitions/Kconfig | 1 +
block/partitions/cmdline.c | 311 ++---
include/linux/cmdline-parser.h | 43 ++
6 files changed, 342 insertions(+), 269 deletions(-)
create mode 100644 block/cmdline-parser.c
create mode 100644 include/linux/cmdline-parser.h
diff --git a/block/Kconfig b/block/Kconfig
index a7e40a7..7f38e40 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -99,6 +99,12 @@ config BLK_DEV_THROTTLING
See Documentation/cgroups/blkio-controller.txt for more information.
+config CMDLINE_PARSER
+ bool Block device command line partition parser
+ default n
+ ---help---
+ Parsing command line, get the partitions information.
+
menu Partition Types
source block/partitions/Kconfig
diff --git a/block/Makefile b/block/Makefile
index 39b76ba..4fa4be5 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched.o
obj-$(CONFIG_BLOCK_COMPAT) += compat_ioctl.o
obj-$(CONFIG_BLK_DEV_INTEGRITY)+= blk-integrity.o
+obj-$(CONFIG_CMDLINE_PARSER) += cmdline-parser.o
diff --git a/block/cmdline-parser.c b/block/cmdline-parser.c
new file mode 100644
index 000..18fb435
--- /dev/null
+++ b/block/cmdline-parser.c
@@ -0,0 +1,249 @@
+/*
+ * Parse command line, get partition information
+ *
+ * Written by Cai Zhiyong caizhiy...@huawei.com
+ *
+ */
+#include linux/buffer_head.h
+#include linux/module.h
+#include linux/cmdline-parser.h
+
+static int parse_subpart(struct cmdline_subpart **subpart, char *partdef)
+{
+ int ret = 0;
+ struct cmdline_subpart *new_subpart;
+
+ *subpart = NULL;
+
+ new_subpart = kzalloc(sizeof(struct cmdline_subpart), GFP_KERNEL);
+ if (!new_subpart)
+ return -ENOMEM;
+
+ if (*partdef == '-') {
+ new_subpart-size = (sector_t)(~0ULL);
+ partdef++;
+ } else {
+ new_subpart-size = (sector_t)memparse(partdef, partdef);
+ if (new_subpart-size (sector_t)PAGE_SIZE) {
+ pr_warn(cmdline partition size is invalid.);
+ ret = -EINVAL;
+ goto fail;
+ }
+ }
+
+ if (*partdef == '@') {
+ partdef++;
+ new_subpart-from = (sector_t)memparse(partdef, partdef);
+ } else {
+ new_subpart-from = (sector_t)(~0ULL);
+ }
+
+ if (*partdef == '(') {
+ int length;
+ char *next = strchr(++partdef, ')');
+
+ if (!next) {
+ pr_warn(cmdline partition format is invalid.);
+ ret = -EINVAL;
+ goto fail;
+ }
+
+ length = min_t(int, next - partdef,
+ sizeof(new_subpart-name) - 1);
+ strncpy(new_subpart-name, partdef, length);
+ new_subpart-name[length] = '\0';
+
+ partdef = ++next;
+ } else
+ new_subpart-name[0] = '\0';
+
+ new_subpart-flags = 0;
+
+ if (!strncmp(partdef, ro, 2)) {
+ new_subpart-flags |= PF_RDONLY;
+ partdef += 2;
+ }
+
+ if (!strncmp(partdef, lk, 2)) {
+ new_subpart-flags |= PF_POWERUP_LOCK;
+ partdef += 2;
+ }
+
+ *subpart = new_subpart;
+ return 0;
+fail:
+ kfree(new_subpart);
+ return ret;
+}
+
+static void free_subpart(struct cmdline_parts *parts)
+{
+ struct cmdline_subpart *subpart;
+
+ while (parts-subpart) {
+ subpart = parts-subpart;
+ parts-subpart = subpart-next_subpart;
+ kfree(subpart);
+ }
+}
+
+static int parse_parts(struct cmdline_parts **parts, const char *bdevdef)
+{
+ int ret = -EINVAL;
+ char *next;
+ int length;
+ struct cmdline_subpart **next_subpart;
+ struct cmdline_parts *newparts;
+ char buf[BDEVNAME_SIZE + 32 + 4];
+
+ *parts = NULL;
+
+ newparts = kzalloc(sizeof(struct cmdline_parts), GFP_KERNEL);
+ if (!newparts)
+ return -ENOMEM;
+
+ next = strchr(bdevdef, ':');
+ if (!next) {
+ pr_warn(cmdline partition has no block device.);
+ goto fail;
+ }
+
+ length = min_t(int, next - bdevdef, sizeof(newparts-name) - 1);
+ strncpy(newparts-name, bdevdef, length);
+ newparts-name[length] = '\0';
+ newparts-nr_subparts = 0;
+
+ next_subpart = newparts-subpart;
+
+
