2011/9/23 Andrei Warkentin <awarkentin@xxxxxxxxxx>:
> Hi Namjae,
>
> I scanned over your changes to enable GP partitions, and while I
> did not yet test your changes, they do appear to be ok.
>
> Please CC me on the next version of your patch so I can give
> it a spin and Ack on it.
>
> I do suggest at least thinking about ways to improve on this. Back
> when I added boot partition support, I already didn't like the fact
> that the block driver had to be aware of the eMMC partitions, with all
> the code duplication and such. By adding four more partitions,
> you've compounded the problem and now you have six pieces of
> code that really look the same.
>
> The core/mmc.c right now scans the size values and stores them
> in mmc_card, and the block driver is smart enough to know what
> to do with them. Why not make the block code generic at the expense
> of keeping an array of structures in mmc_card? The block driver
> would then just iterate over these and create the additional devices. The partition
> switch routine would then operate on these structures, and could then be pulled out
> of the block driver, making it simpler.
>
> Each physical partition could be described by something like -
> struct mmc_part {
> unsigned int size;
> unsigned int cookie; /* for mmc, idx used in mmc_switch, part_type from current mmc_blk_data */
> char name[DISK_NAME_LEN];
> bool force_ro; /* to make boot parts RO by default */
> };
>
> Just an idea. Clearly, if MMC grows by another 4-5 possible partitions, it's not
> realistic to be copy-pasting the same block of code, nor would it make sense
> if/when these types of devices support an arbitrary amount of physical partitions.
>
> Thanks,
> A
>
Okay, I understand what you want. I will try to make patch included
your suggestion again.
Thanks for your review.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
