Re: [patch 00/13] devtmpfs patches

[ebiederm@xmission.com (Eric W. Biederman)]

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

>> 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 fully expect people to ask if we want people to maintain my code
forever.

I need to extend to you a small apology you were blasting Arjan and
had added me to the CC, and I thought it was a reply to something I
wrote so my context was wrong, and I reacted more strongly than I
would have otherwise.

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

Which has been my question all along where is the kernel slow?

>> 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 see statements like:
"several seconds" (Your original patch)
"boot speed boot speed boot speed" (You)
"1-2 seconds" (GregKH)

And I got the impression that a very slowly running udev is what you
are trying to solve.

Your numbers actually only show a 1 second net gain on kvm.  Although
it is hard to tell what is happening.

It sounds like what you are really trying to solve is to allow more
things to run in parallel with udev.  I believe there is a very simple
way to do that.

At udevd start.
mount /dev
mknod /dev/console
mknod /dev/zero
mknod /dev/null
(and maybe a few other well know device nodes)
daemonize (to stop serializing other processes)
dynamically create everything else by looking at sysfs.

That should have a trivial serialized cost, and allow you to take
whatever time it is you need to serialize device creation.

It has the downside that it opens up the window between when devices
are in sysfs and devices are in /dev, but I don't see it creating
any new races.

Eric