Hi, On Tue, Apr 5, 2016 at 7:00 PM, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> wrote: >> I am not immediately opposed to this patch, although let me think a >> bit more about it. >> >> What I would like to understand is why UUID/PARTUUID isn't working for >> your case. Did you try to use that? > > I have used with UUID/PARTUUID/PARTLABEL and etc.. I think it's not problem. > But that is why some guys wants to use the fixed index. > (Almost all SoCs are still using "root=mmcblk0pX" in bootloader.) > > I'm considering more what is better. :) I like the idea of consistent numbering here. IMHO that solves a few different problems: 1. For poor, feeble-minded humans like me, have sane numbering for devices helps a lot. When grepping through dmesg it's terribly handy if a given SDMMC device has a consistent number. I know that I can do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about the eMMC. I know that I can do "dmesg | grep mmc1" to find info about the SD card slot. I don't want it to matter which one probed first, I don't want it to matter if I'm working on a variant of the hardware that has the SD card slot disabled, and I don't want to care what my boot device was. Worrying about what device number I got increases my cognitive load. 2. There are cases where it's not trivially easy during development to use the UUID. Specifically I work a lot with coreboot / depthcharge as a BIOS. When configured properly, that BIOS has a nice feature to allow you to fetch the kernel and kernel command line from TFTP by pressing Ctrl-N. In this particular case the BIOS doesn't actually know which disk I'd like for my root filesystem, so it's not so easy for it to put the right UUID into the command line. For this purpose, knowing that "mmcblk0" will always refer to eMMC is handy. Note that I would personally prefer that the old patches to solve this problem were resurrected. Those old patches: * Also ensure consistent numbering for "mmc", not just "mmcblk" * Are slightly cleaner in the "mmcblk". I've just rebased and cleaned up those patches and included the Documentation from here. I'll post them now. -Doug -- 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
