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]

Message-ID: <20160429212920.GA19428@n2100.arm.linux.org.uk>
Date:	Fri, 29 Apr 2016 22:29:20 +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 02:17:45PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 2:13 PM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 01:04:48PM -0700, Doug Anderson wrote:
> >> Russell,
> >>
> >> On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
> >> <linux@....linux.org.uk> 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?
> >
> > This discussion is over, since you're not willing to actually discuss
> > it (illustrated by you cutting and pasting this same thing four
> > times in your reply.)
> >
> > My NAK stands until such time that you can partake in a reasonable
> > discussion.
> 
> The point of pasting it several times was that you'd answer it.
> Apparently that failed.
> 
> Perhaps you could answer the question I posed?

No, because you haven't taken the time to think and consider my
reply, which gives you insight into how your "problem" is no
different from the situation that everyone else has, where it
isn't a problem.

I think the "problem" here is that you've got used to coreboot
doing something that very few other boot loaders do, namely it
automatically extracting a rootfs UUID for you.  The rest of the
world doesn't have that luxury.

So, instead, you want to stuff more code into the kernel to work
around what you think is a problem - a problem which seems to be
unique to yourself.

The UUID and label solutions were created by x86 people to work
around exactly this dynamic device problem, and as my previous
replies have shown, it is superior to fixing the device assignment
as you're trying to do.

However, I don't expect that you'll like this answer, and you'll
probably just re-post your same question after each and every
paragraph rather than considering whether the already existing
solutions could solve your "problem".  So I'm just wasting my time.

This is my last reply.

-- 
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.