Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree
From: Russell King - ARM Linux <hidden>
Date: 2016-04-29 19:58:16
Also in:
linux-arm-kernel, linux-mmc, linux-rockchip, lkml
On Fri, Apr 29, 2016 at 12:43:39PM -0700, Doug Anderson wrote:
Russell, On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux [off-list ref] wrote:quoted
On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:quoted
This series picks patches from various different places to produce what I consider the best solution to getting consistent mmc and mmcblk ordering. Why consistent ordering and why not just use UUIDs? IMHO consistent ordering solves a few different problems:NAK. Really. Use UUIDs, that's the proper solution here.Un-NAK. UUIDs don't solve point #1.
Re-NAK. I don't think your point #1 is valid. See my other reply.
* Presumably on a PC you've got an extra bit in the middle (like grub or something like that) that can help you resolve your UUIDs even if you get your kernel from somewhere else.
You are over-estimating what grub does. Grub doesn't resolve UUIDs at all. Grub just passes the kernel arguments in its configuration file for the entry it is booting to the kernel. It's a static configuration found in /boot/grub/grub.conf. It doesn't probe devices for UUIDs.
* Presumably in the non-embedded world kernel hackers have a different workflow. They probably don't swap between different devices with different configurations on an hourly basis. They're not in the habit of totally reimaging their system periodically. Etc. Trying to force the workflow of a PC kernel hacker and an embedded kernel hacker to be the same doesn't seem like a worthwhile goal.
In _my_ world with the "embedded" devices I have, I mount by UUID on platforms which have multiple MMC devices to avoid exactly the problem you're having. This works fine. If I were to switch the SD card, and I wanted to avoid changing the boot loader configuration, I'd use label instead, and I'd label all the SD card rootfs using the same label so I could just swap the cards.
* Presumably an embedded kernel hacker running with ATA / SCSI could _usually_ assume that "sda" is his/her root filesystem. It's unlikely an embedded system would have more than one "sda" disk builtin and it's nearly guaranteed (I think) that a builtin ATA / SCSI controller would probe before any USB based devices.
You've got a funny view again. N2100 has two hard disks. The clearfog board from SolidRun has two mini-PCIe slots, each of which can have two SATA interfaces... If you want to use it as a server-type platform with lots of disks...
Sure, if your root filesystem is USB based (really?) and you've got additional USB storage devices then you're SOL. Sorry.
One of my Versatile Express platforms boots from USB, and has a MMC slot... So this argument does not stack up. Sorry. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.