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]
Date:	Fri, 29 Apr 2016 09:21:19 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Douglas Anderson <dianders@...omium.org>
Cc:	Jaehoon Chung <jh80.chung@...sung.com>,
	Shawn Lin <shawn.lin@...k-chips.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Stefan Agner <stefan@...er.ch>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	Brian Norris <computersforpeace@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	Venu Byravarasu <vbyravarasu@...dia.com>,
	Justin Wang (王丁) 
	<justin.wang@...eadtrum.com>, ksumrall@...roid.com,
	Lars-Peter Clausen <lars@...afoo.de>,
	Dmitry Torokhov <dtor@...omium.org>,
	Jon Hunter <jonathanh@...dia.com>,
	Tao Huang <huangtao@...k-chips.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Paweł Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>,
	Rob Herring <robh+dt@...nel.org>,
	"Dong, Chuanxiao" <chuanxiao.dong@...el.com>,
	Chaotian Jing <chaotian.jing@...iatek.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

On 29 April 2016 at 01:06, Douglas Anderson <dianders@...omium.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.
>
>
> 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(-)
>
> --
> 2.8.0.rc3.226.g39d4020
>

I believe you need to re-base this patchset as things have changed.

Currently the mmc host index that gets picked at host registration
point, will also be given to the corresponding mmc block device index.
That's probably solving most of your concerns, but I am open to extend
this to cover aliases as well, as to allow it to be *really*
deterministic.

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ