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

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 12:31:28PM -0700, Doug Anderson wrote:
> Rob,
> 
> On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring <robh+dt at kernel.org> wrote:
> > On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
> > <dianders at chromium.org> wrote:
> >> 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:
> >>
> >> 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.
> >
> > Why don't you use labels? This works whether your rootfs is on
> > /dev/vdXy, /dev/sdXy or /dev/mmcblkXpy.
> 
> I've never used labels.  I can take a look at them.  I presume I'll
> have to do a little extra work to tag my "emmc" filesystem properly
> when I install to eMMC, but that wouldn't be too bad.  Thanks for the
> suggestion.
> 
> That solves point #2, but not point #1.  It still adds an extra step
> of mapping number to device when looking at logs / sysfs files.

Your original two arguments don't really stand up.

Let's take #2 to start with.

You claim that coreboot doesn't have support to provide the correct UUID.
Why is that a problem?  Distros on x86 don't have support to provide the
correct UUID either.  That's done by the distro when setting the system
up - it provides the kernel loader (eg, grub) with an appropriate
configuration, which includes a root specifier with the correct UUID,
eg:

 root=UUID=a5dcd879-eea2-4d87-bdef-8ee76741e7df

That's for the initramfs to use, but there's a short UUID equivalent for
the kernel itself, or as Rob and myself have already pointed out, the
label system (which is problematical if you have multiple filesystems
with the same label.)  UUID is the better system.

For #1, are you really saying that you're somehow different from all the
x86 platform users, and can't cope with dynamic numbering of devices that
are present on x86 systems?

> It would be quite easy to adjust this to other systems if they
> provided similar functionality.  Nearly 100% of this code is just
> calling helper functions, so the code would be easy to find and change
> if/when there was a generic (non-DT) method for this.

Except the problem is already solved by the UUID or label mount methods,
which work everywhere, even across different media.  So, if you decide
to plug your SD card into a USB reader because the SD slot has become
unreliable, if you mount by UUID or label, the kernel will still find
the right device, even though it's now become /dev/sd* instead of
/dev/mmcblk*.

> > If consistent numbering for devices is a goal in the kernel, then I'd
> > feel otherwise. But I'm pretty sure that is a non-goal.
> 
> Can you provide documentation that this is a non-goal?  I can submit
> some patches upstream to make ID allocation behave more randomly if
> that would be helpful to upstream.  I'd probably want to disable it
> locally, but if you think folks would really like it...  ;)
> 
> In all seriousness, though, I'm not sure why randomness in IDs would
> be considered a worthwhile goal.

*Sigh* you're taking this to an extreme.  Random numbering isn't a goal
in itself.  The kernel just doesn't provide a _guarantee_ the order in
which devices appear or the names which the devices will get.

It means that you _can_ mount by device path if you wish, but you may
occasionally run into cases where the device path changes for one
reason or another (eg, because you've changed the PCIe card slot that
your SATA PCIe card is plugged into, or many other reasons.)

Just use UUID (preferred) or label and enjoy much more flexibility than
your solution adding yet more code to the kernel would give you.

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