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 15:22:50 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
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

Hi,

On Fri, Apr 29, 2016 at 3:16 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
>> <linux@....linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
>> > [didn't read most of your reply]
>> >
>> >> Really I just reposted it several times because I notice that you seem
>> >> to ignore many points of my emails.  I was really hoping to get you to
>> >> address this point.  I notice that you still didn't.  Either you are
>> >> just trying to annoy me, or you don't have an answer to how my patch
>> >> series hurts you.
>> >
>> > I don't see you treating Rob with the same contempt that you have
>> > treated me in this thread, despite Rob and myself both telling you
>> > basically the same thing.
>>
>> Rob wrote a nice thoughtful reply and I tried to give a nice
>> thoughtful reply back to him.  He raised some good points and I raised
>> some good points back to him.  I look forward to his future thoughts
>> on the topic.
>
> Meanwhile, I've pointed out that you appear to be coming from a
> misunderstanding (that's certainly clear because you believed
> initially that grub did something it doesn't), showing that the
> "problem" you have is no different from the majority of other
> systems running Linux, and you treat me with contempt.
>
> What are you going to do to resolve this?

As I tried to indicate in earlier emails, I don't actually care how
grub works in this case.  It was originally meant to illustrate the
other people's workflows and mine are not the same.  If they have a
solution that works for them, that's great.

I want my MMC and MMCBLK device numbers to be sane and consistent to
help me parse through dmesg and sysfs.  If it happens to also make it
easy / possible to specify a root filesystem using "mmcblkN" that's
great and I'll probably take advantage of that.

I'm very sorry if those using SATA and ATA disks don't have a way to
get sane and consistent device number ordering.  I really am.  ...but
just because they don't have a well defined ordering doesn't mean
those of us using MMC should have to suffer.  ...and I don't think
giving a sane ordering to MMC devices hurts anyone, does it?

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ