Re: [patch 00/13] devtmpfs patches

[Kay Sievers]

On Mon, May 11, 2009 at 04:36, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>> Devtmpfs is the simplest, is the fastest, is the most reliable, and it
>> is the most flexible
>
> FLEXIBLE?

Yes, flexible because you can do whatever you want in whatever order
and never run into problems with an empty /dev. You can even just
ignore /dev and go ahead. There are basically no dependencyies to do
other things in parallel.

>> 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 would be very careful with such statement if you want us to accept
your namespace hacks in the future. I guess if we ask with your next
round "do we want to to have to maintain this for forever" you get a
very different answer than today.

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

No, I did decide to ship it in the distro which is how things work
since forever. And it's not in the upstream kernel now, while this
discussion happens.

>> You might not like it for whatever reason.
>
> I think your justification for this ``feature'' is strongly flawed.

I did not hear any substantial technical argument so far.

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

The made up numbers you are bringing up here, suggest that you never
worked in that area, and really, can you please talk about things you
have experience with, or get the needed one _before_ calling things
"flawed", "slow". You even suggest non-working racy hacks instead,
which is far from funny.

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

Again. nothing is dog-slow. We just don't do unreliable bad hacks like
you suggest. Have you ever wondered why _every_ distro does it this
way? Maybe they are all stupid and just wait for you to tell them and
solve their problem.

>> And we consider this problem as solved.
>
> What backroom have you had that discussion?

I wrote like ten times as many words as are in the patch, here in this
thread. I don't think there is any backroom here.

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

Oh, like calling stuff "flawed", "dog-slow", while not even seen any
of this running for real?

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

That's utter nonsense. It's not slow at all, it's just slower that
what we can do with the bit of help from the kernel.

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

Can you read? Did you read the many reasons why we want this? I guess not.

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

You seem running in circles with searching for a "suspicion". Care to
provide a technical argument for the first time? That would be
appreciated.

Thanks,
Kay
--
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/