linux-kernel - Re: [patch 00/13] devtmpfs patches

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: <ac3eb2510905110434nb123423m134e848c17c3c736@mail.gmail.com>
Date:	Mon, 11 May 2009 13:34:52 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Fabio Comolli <fabio.comolli@...il.com>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] devtmpfs patches

On Mon, May 11, 2009 at 12:55, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> You've yet to demonstrate
> - That your patches are a real speed up

And I did, and it's obvious that creating a single file along with the
~10 we already create in /sys, instead of running through /sys or
/proc later and reconstruct what we missed, is always, and in every
case faster and simpler. It gets rid of a bunch of things we need to
do today, and depending how much of the things you remove, you get
faster. It's a different model and hard to compare directly. But for a
fact, you can never be faster than the kernel provided nodes.

> - That dumping more crap in kernel without policy and management is a
>  good idea

What exactly do you find is "crap"? What do you mean with "management"?

> - That the other proposals are worse than yours.

I also did, in exactly this thread.

> Arjan produced detailed boot graphs and boots a box very fast indeed. I
> see no boot graphs, no detailed analysis here.

I did in a reply to your earlier mail. And also mentioned the
init=/bin/sh case, which I think, would be reason enough alone,
without all the other gains, to do that.

> Instead we have obnoxious threats to Eric Biederman and an "I am going to
> ram this into the kernel whatever" approach.

Nobody says such thing. I just defend against "dog-slow", "backroom",
and the proposal of even more broken hacks to solve this very problem.
There is no hammering at all, it's just my personal discomfort with
replies who ignore the real issues, and bring up false facts.

> Neither are constructive or useful and this isn't the way the Linux
> kernel project works.

You might be right here, I don't disagree. It's becoming more a
personal issue than a technical, and sorry for that. But stuff like
this happens sometimes, and it's also sometimes "how the kernel
project works". :) Again, sorry.

> Yes maybe you can stuff things into Greg's tree
> easily because you both work for SuSE but that isn't the right way to do
> stuff for upstream.

Come on. You can not convince Greg about anything, just because you
happen to work for the same company. Many of us share a company with
others, also you did in the past and you do now - and we will get
nowhere bringing up such conspiracy statements.

We came up with this, because we think it is the right thing, and it
has proven to solve our problems, and I'm personally still convinced
it is the best option, that's all.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/