Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752668AbcD2Tno (ORCPT ); Fri, 29 Apr 2016 15:43:44 -0400 Received: from mail-yw0-f177.google.com ([209.85.161.177]:34114 "EHLO mail-yw0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752347AbcD2Tnl (ORCPT ); Fri, 29 Apr 2016 15:43:41 -0400 MIME-Version: 1.0 In-Reply-To: <20160429181248.GW19428@n2100.arm.linux.org.uk> References: <1461951139-6109-1-git-send-email-dianders@chromium.org> <20160429181248.GW19428@n2100.arm.linux.org.uk> Date: Fri, 29 Apr 2016 12:43:39 -0700 X-Google-Sender-Auth: cLW3JroynkIHwSTslyEVcorLgTc Message-ID: Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree From: Doug Anderson To: Russell King - ARM Linux Cc: Ulf Hansson , Jaehoon Chung , Shawn Lin , Adrian Hunter , Stefan Agner , "linux-mmc@vger.kernel.org" , Brian Norris , Dmitry Torokhov , Heiko Stuebner , Jisheng Zhang , "open list:ARM/Rockchip SoC..." , devicetree-spec@vger.kernel.org, Mark Rutland , "linux-kernel@vger.kernel.org" , Venu Byravarasu , Lars-Peter Clausen , Jon Hunter , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , Pawel Moll , Ian Campbell , Grant Grundler , Kumar Gala , "Luca Porzio (lporzio)" , Rob Herring , Chaotian Jing , Sergei Shtylyov , Sudeep Holla , zhonghui.fu@linux.intel.com, kirill.shutemov@linux.intel.com Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2274 Lines: 52 Russell, On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux 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. > Exactly the same issue arises if you have more than one ATA or SCSI > adapter in your PC - things can be probed out of order and end up > in different /dev/sd* slots. Yup, UUIDs are awesome and great and super. Best invention since sliced bread, really. I definitely _won't_ submit a patch to remove UUID support. I promise. A few notes, though: * 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. In my case, I don't have that. Maybe this is a failing of coreboot / depthcharge's netboot and I suppose. ...and I suppose I could modify the BIOS to take a root filesystem of "eMMC" and have it resolve that to the eMMC's UUID or something like that. ...or I just take these patches locally and things keep working like they did before. * 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. * 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. Sure, if your root filesystem is USB based (really?) and you've got additional USB storage devices then you're SOL. Sorry. -Doug