Thread (29 messages) 29 messages, 7 authors, 2016-05-04

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help