Hi, On Sat, 25 Aug 2012 05:26:51 -0400 Huang Shijie <shij...@gmail.com> wrote: > On Sat, Aug 25, 2012 at 5:02 AM, Shmulik Ladkani > <shmulik.ladk...@gmail.com> wrote: > > Your analysis seems right, but let me offer an alternative approach. > > > > I would simply: > > > > - part->num_parts = i; > your code does not wors in such kernel command line(also with the 1GB > nand chip): > #gpmi-nand:100m(root),100m(kernel),1g(rootfs),1g(user),-(rest) >
Can you please detail what do you mean by "not work"? To my understanding, in this example, according to my suggestion, the resulting partitions would be: root 100m@0 kernel 100m@100m rootfs 800m@200m (truncated) user 0@1g (truncated) rest 0@1g Reasonable IMO, given the fact that the mtd device size is smaller than the specified parts. I saw you submitted a patch which sorts the cmdline parts; I don't understand why this is necessary. Also, sorting might not be desirable, as the user specified the unsorted partitions might have _wanted_ them to appear in that order. Now lets focus on your original suggestion and its consequences: - Orignal code STOPPED parsing at the 1st truncated partition, this partition WAS NOT returned to the caller - Your patch STOPS AFTER parsing the 1st truncated partition, this partiton IS returned to the caller (but partitions specified later are no longer parsed) - My suggestion CONTINUES parsing all partitions. So later partitions (specified with the 'size' but *without* 'offset') will be truncated AND presented to the caller. AND, if later partitions are specified using the 'size@offset' explicit format, they are parsed normally. Regards, Shmulik -- 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/