2011/9/23 Andrei Warkentin <[email protected]>: > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
