linux-kernel - Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

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 20:57:41 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	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@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Brian Norris <computersforpeace@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Jisheng Zhang <jszhang@...vell.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	devicetree-spec@...r.kernel.org,
	Mark Rutland <mark.rutland@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Venu Byravarasu <vbyravarasu@...dia.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Jon Hunter <jonathanh@...dia.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Grant Grundler <grundler@...omium.org>,
	Kumar Gala <galak@...eaurora.org>,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>,
	Rob Herring <robh+dt@...nel.org>,
	Chaotian Jing <chaotian.jing@...iatek.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Sudeep Holla <sudeep.holla@....com>,
	zhonghui.fu@...ux.intel.com, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk
 numbering w/ device tree

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
> <linux@....linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 10:32:15AM -0700, 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:
> >
> > 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.