On Fri, Apr 1, 2011 at 5:38 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > Even if they are write-once, wouldn't we still need to provide an > interface to write them once? > True. I first wanted to provide access to them. It would have to be a special ioctl. There are a number of interesting MMC operations that don't fit any other way - for example, password protection. > The question if GP should be used together or instead of MS-DOS > partitions depends on the possible use cases. If you don't want > to partition a GP any further in software, exposing them directly > as mmcblk0pX would be a very nice and simple interface, but > it completely prevents you from creating subpartitions. > > The other alternative is to allow each GP to contain a partition > table, but then you need a either a three-level naming (mmcblk0gp1p2) > or make each GP a device by itself (mmcblk0, mmcblk1) that can in > turn be partitioned. > Right now they are exposed as separate devices. This lets the user pick whatever usage they see fit (can format it directly, or can partition it), while the naming (mmcblk0boot0, mmcblk0boot1, mmcblkgp0p1 for first partition on gp0, for example) conveys that the entries are for device partitions. >> > Regarding the naming, I would not use a trailing zero, but it's probably >> > a subjective thing. The other names I could imagine for the boot partition >> > of mmc 0 are mmcboot0, mmcblk0b or mmcblk0boot. >> > >> >> Since we have two boot partitions and 4 GP ones, for mmcblk0 I'd stick >> with something like >> mmcblk0boot0, mmcblk0boot1, mmcblk0gp0-mmcblk0gp4. I'd want to keep >> the first mmcblk0, so that >> a user can easily associate the actual card the device partitions are for. > > I would find it rather confusing if the device can be partitioned in > software but the GP devices could not be. > Right now you can partition the device partitions, because effectively, they are separate devices. 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
