On Wed, Mar 30, 2011 at 6:34 PM, Chris Ball <c...@laptop.org> wrote: > Hi, > > On Wed, Mar 30 2011, Andrei Warkentin wrote: >> 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. > > Ah. Ugh, that sucks; I can totally see that happening. Now I'm > wondering if we should just be hardcoding boot devices as always > read-only and just refusing to write to them. > > What do others think? Is there an acceptable tradeoff somewhere? > It's not clear to me that Kconfig entries are sufficient to obtain > consent to present r/w mounts of the boot partitions; the user > writing the "dd" line usually isn't the person who made the Kconfig > selection, and the person who made the Kconfig selection is often a > distro maintainer who just turns on new Kconfig symbols without > reading closely. >
Well, there are less esoteric ways of turning something into a paperweight =). No, the whole point of adding the device partition support is so you don't have to go through hoops to read and write them. The scenario where it matters (embedded Linux devices booting through boot partitions) are such, that if you went through sufficient hoops to get root access, and can build and boot a kernel to enable these options for that device, then you must know what you're doing, and a warning message in the Kconfig help is sufficient. The generic case of people sticking cards into a PCI SDHCI controller under Ubuntu is such that you can do no real damage. A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
