Re: [patch 00/13] devtmpfs patches

[Eric W. Biederman]

Kay Sievers <kay.sievers@xxxxxxxx> writes:

> On Mon, May 11, 2009 at 02:00, Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/