linux-kernel - Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1659435.FBgTBXnguZ@wuerfel>
Date:	Fri, 29 Apr 2016 19:39:09 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Douglas Anderson <dianders@...omium.org>
Cc:	ulf.hansson@...aro.org, jh80.chung@...sung.com,
	shawn.lin@...k-chips.com, adrian.hunter@...el.com, stefan@...er.ch,
	linux-mmc@...r.kernel.org, computersforpeace@...il.com,
	dmitry.torokhov@...il.com, mark.rutland@....com,
	vbyravarasu@...dia.com, justin.wang@...eadtrum.com,
	ksumrall@...roid.com, lars@...afoo.de, dtor@...omium.org,
	jonathanh@...dia.com, huangtao@...k-chips.com,
	devicetree@...r.kernel.org, pawel.moll@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	lporzio@...ron.com, robh+dt@...nel.org, chuanxiao.dong@...el.com,
	chaotian.jing@...iatek.com, sergei.shtylyov@...entembedded.com,
	linux-kernel@...r.kernel.org, sudeep.holla@....com
Subject: Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

On Thursday 28 April 2016 16:06:42 Douglas Anderson 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.
> 
> 
> Jaehoon Chung (1):
>   Documentation: mmc: Document mmc aliases
> 
> Stefan Agner (2):
>   mmc: read mmc alias from device tree
>   mmc: use SD/MMC host ID for block device name ID
> 
>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
>  drivers/mmc/card/block.c                      |  3 ++-
>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>  3 files changed, 33 insertions(+), 6 deletions(-)


Does this mean we can revert 9aaf343 ("mmc: block: Use the mmc host
device index as the mmcblk device index") for now and wait until this
is in as well?

The commit I mention here breaks a significant number of boots
on Olof's test build setup, and it would be nice to avoid breaking
them again when we get yet another device numbering system.

	Arnd