Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752793AbcD2UEw (ORCPT ); Fri, 29 Apr 2016 16:04:52 -0400 Received: from mail-yw0-f181.google.com ([209.85.161.181]:36857 "EHLO mail-yw0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752487AbcD2UEt (ORCPT ); Fri, 29 Apr 2016 16:04:49 -0400 MIME-Version: 1.0 In-Reply-To: <20160429195741.GY19428@n2100.arm.linux.org.uk> References: <1461951139-6109-1-git-send-email-dianders@chromium.org> <20160429181248.GW19428@n2100.arm.linux.org.uk> <20160429195741.GY19428@n2100.arm.linux.org.uk> Date: Fri, 29 Apr 2016 13:04:48 -0700 X-Google-Sender-Auth: jmCFvH84EbFXyOzylESKiCnXQ-c 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: 2918 Lines: 69 Russell, On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux wrote: >> * 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. OK. The point was: if folks on PCs have a workflow that works for them, wonderful. That workflow doesn't work so great for me. My workflow doesn't hurt them. Why is it bad? >> * 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. OK. The point was: if you have a workflow that works for you, wonderful. That workflow doesn't work so great for me. My workflow doesn't hurt you. Why is it bad? >> * 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... OK. The point was: if you have a workflow that works for you, wonderful. That workflow doesn't work so great for me. My workflow doesn't hurt you. Why is it bad? >> 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. OK. The point was: if you have a workflow that works for you, wonderful. That workflow doesn't work so great for me. My workflow doesn't hurt you. Why is it bad? -Doug