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-next>] [day] [month] [year] [list]

Date:	Sun, 10 May 2009 19:36:46 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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

Kay Sievers <kay.sievers@...y.org> writes:

> On Mon, May 11, 2009 at 02:00, Arjan van de Ven <arjan@...radead.org> wrote:
>> (and it seems to be irrelevant to the devtmpfs discussion anyway since
>> Eric Biederman has shown that pulling the device numbers out of sysfs
>> is basically free... even though it'd be nice to give that some help to
>> make it a nice index)

> Devtmpfs is the simplest, is the fastest, is the most reliable, and it
> is the most flexible 

FLEXIBLE?

> option for us. And still, nobody will be forced
> to use it, it's entirely optional. For our systems, we decided to do
> it that way, and we ship it already in the distro, and if there are no
> substantial problems coming up, which we don't expect, we will
> continue using it.

Yes but you are asking all of us to maintain it.  Forever in perpetuity.
A better case needs to be made than you have already shipped the code.

I'm sorry you decided to ship the code before getting a review.  I
guess that is the definition of an experimental feature.  One not in
the upstream kernel.

> You might not like it for whatever reason.

I think your justification for this ``feature'' is strongly flawed.

You claim to save 2 seconds of a process that should take less than
a tenth of a second.

You claim flexibility while removing user space from the policy loop.

You claim speed increases when comparing to a dog slow non-tuned
implementation.

> And we consider this problem as solved.

What backroom have you had that discussion?

You are presenting this as a decision already made.  I think you
are not playing well with others.

I don't see a case having been made that the existing user
space interface is broken.  Just that the udev implementation
is slow.

I think a slow user space application is simply not a justification
for putting code in the kernel.

I think a developer using faulty arguments for their code likely
has not thought things through and that is enough reason to call
suspicion onto the code in my opinion.

Eric
--
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/