Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

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

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

>> My primary concern is that you are inventing a new mechanism when
>> the existing mechanism has known issues that could explain the slowdowns.
>
> You mean that mounting a new tmpfs at /dev has the issue of being
> empty?

I was thinking more along the lines of a single global lock for all of
sysfs,.

> And it takes time to fill it, where you can't reliably do other
> things at the same time that might need device nodes? Yeah, I guess
> that's an issue with the existing mechanism, and I'm interested in
> your proposal to solve it.

As for that question why not.

initramfs has always come prepopulated with device nodes.

It isn't a challenge to mount a new tmpfs somewhere else populate it
with the basics and them move it onto tmp.

I would be very surprised if you needed much more than /dev/console,
/dev/zero and /dev/null for reliable operation of most programs.

The rest just looks like ensuring you can deal with root (or what
ever device you care about) showing up after things start running.
With usb devices apparently not having a guaranteed maximum wait
and things like dhcp required for network connectivity I don't see
where adding code to wait for you device to show up would be
unnecessary logic.

That said it might make sense to be able to kick off udevd or similar
before /sbin/init was exec'd.  I don't know how much that would gain.

Numbers like 2 seconds sound absolutely huge in cpu time.  And I don't
have a clue why udev would take anywhere near that long even doing
everything synchronously.  Have you instrumented things up to
see what takes that much time?

Eric