[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote:
> Maybe a third opinion could make this conversation constructive again.
> 
> I think Doug's point is that using a UUID or labels for consistency is
> orthogonal to having a deterministic numbering for MMC devices. And I
> agree with his point of view for what is worth.

Yes, it may be orthogonal, but there are two issues here:

1. How does the system know which MMC device to mount for its rootfs.

This is the point that I've picked up on, which has been solved for
years, and actually pre-dates MMC support in the kernel, and that is
mount by UUID.

The kernel itself has no support for mount-by-label, which is normally
solved by using an initramfs, which contains programs such as mount
etc which will scan the block devices looking for an appropriately
labelled filesystem.  Label has slightly more issues since its possible
that you could end up with two filesystems with the same label (eg, on
x86, you're migrating your disks, and you plug in a disk which has a
label of "/" but is not your intended rootfs.)

Of course, any scheme which relies on an identifier on the disk may
result in some kind of clash if another partition/disk has the same
identifier.

2. The identifier found in kernel messages for each MMC device.

This is where Doug and myself disagree.  I don't see this as a big
problem - the big problem is (1) above, which is the one which can
lead to a non-functional system.  I believe that the actual name
that we end up with is a cosmetic issue.

What I've been trying to point out is that the same cosmetic issue
occurs elsewhere in the kernel, particularly with disks on SATA
interfaces.  I've lost count of the number of times that my IDE
disks on one of my machines have changed between /dev/hda, /dev/hdc,
/dev/sda, /dev/sdc, etc.  Thankfully, these are part of a raid
array, and they are always constructed to appear as /dev/md* devices
which are the devices that are mounted.

The device names that they end up with depend on which drivers are
built-in to the kernel, and the order in which the device drivers
and devices are probed.  There's no way to tell the kernel "I want
PCI card X socket Y to be _this_ device name" and that's a concious
decision that was made years ago.

However, it's a cosmetic issue - reading the log reveals which is
which, and MMC is no different - the information required is in the
log.

Here's some material on the problem:

http://www.tldp.org/HOWTO/Partition/devices.html
http://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x99.html
https://lkml.org/lkml/1997/5/4/54
http://marc.info/?l=linux-raid&m=113595057816321&w=2

The first two show that it's well understood (and documented) that
storage devices are dynamically assigned and variable.

The third is an example of how old this problem is - almost twenty
years old, and it hasn't been "solved" on x86 except by using UUID/
labels.

The forth is an example of the "problem" that this dynamic device
assignment causes, and again shows that kernel folk have chosen
not to solve it by way of the problem still existing today.

I guess I don't see it as much of problem because I've been doing
this for over a decade.

Now, thinking outside the box - if it's desirable for eMMC to be
treated differently from regular MMC slots, maybe the solution to
this problem is to have eMMC occupy a separate namespace, rather
than using the /dev/mmcblk* namespace.  IOW, /dev/emmc* ?

The /dev/mmcblk* namespace was designed (by me) to be dynamic,
because MMC (not SD) bus structure allows for multiple cards on the
same MMC host interface, much like a SCSI bus allows for multiple
devices on the same cable.  Hence, tying individual mmcblkN to
the mmcN host interface is wrong.

-- 
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.