On Thu, Mar 31, 2011 at 6:17 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > My feeling is that these should be separate from the boot partition. > It could probably be done using a new fs/partitions/mmc.c file > that directly interacts with the mmc layer instead of looking > at the MS-DOS master boot record. That way, you could define the > same partitions (mmcblk0p1, ...) using a different method. > Nope. The device partitions are one time programmable (partition once), so you definitely don't want to expose them as regular partitions. The point behind the GP partitions is that they can be implemented with enhanced features (such as better reliability), and so like the enhanced area, are meant as a complement, not a replacement for file system partitions. I don't think there is a need to over complicate this. It's just going to get more confusing and involve more changes. The device partitioning support is pretty orthogonal right now. > >> There is also the "Replay Protected Memory Block" device partition, >> which is not able to host a file system in the normal sense (because >> layer over the MMC block transfer protocol is a "replay protected >> transaction" protocol, which could be used by a user-mode application >> directly reading/writing from /dev/block/mmcblkXXX). > > Ok. That sounds like a use case for an ioctl interface then, if > we even want to expose it. > Pretty much. > 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 also mentioned the character device option. Yet another way would be > to add a sysfs_bin_attribute that corresponds to the boot partition and > can be accessed using read/write, like we do for PCI resources. I don't think this gains anything, other than a separate path for performing I/O, inability to use existing tools (filesystems, dd, etc) more code and a even less obvious way of bricking something =). 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
