On Wed, Mar 30, 2011 at 5:46 PM, Chris Ball <cjb@xxxxxxxxxx> wrote: > Hi, > > On Wed, Mar 30 2011, Chris Ball wrote: >> Hi Andrei, >> >> On Wed, Mar 30 2011, Andrei Warkentin wrote: >>> Unfortunately yes, although I am open for suggestions. An idea I >>> considered is to add a postfix for device partitions. So, for card 0, >>> the user area will remain mmcblk0, while boot partitions will be >>> mmcblk0b0 and mmcblk0b1, generic partitions will be mmcblk0g0, and so >>> on. >> >> Like Arnd, my main concern was around naming, breaking boot setups, and >> freaking people out by telling them that their cards have block devices >> that they can't usually see and not making it obvious where they came >> from. :) >> >> Your "b/g" postfix solution appears to fix all of these, so I like it. >> We still have to think about where we expect users wondering what the >> "b" and "g" mean to go in order to find out.. > Ok, I'll add that in. I'll add the documentation changes as well. > Oh, one more thing -- if we go with the b/g postfix, what's the > intuition for requiring a Kconfig entry to turn this on? Is there > any good argument against just turning it on for everyone, as long > as it's not affecting mmcblk*p* naming? > The boot partition support (and any other XYZ partition support in the future) so far in the patch is a Kconfig entry. So you have to want it to get it. The argument against turning it on by default is that someone might figure that mke2fs-ing the boot partitions is a good way to reclaim 4MB on their rooted device, and if they didn't realize the data was necessary for boot-up, they will brick the device. That and people might freak out when they see more mmcblk entries than they expected :-). A -- 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
