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

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, May 1, 2009 at 14:38, Alan Jenkins
<sourcejedi.lkml@googlemail.com> wrote:
> On 5/1/09, Kay Sievers <kay.sievers@vrfy.org> wrote:

> I thought it was a useful comparison.  Start udev early enough, and
> you could avoid re-doing absolutely anything.  Thinking about, the
> reasons it doesn't work are
>
> a) running before /dev/null and /dev/console requires hacks
> b) it requires an initramfs
> c) it pulls everything that hooks into or otherwise affects udev into
> the initramfs; that's much more than we have at present, and a bigger
> initramfs' can only make bootup _slower_.

Exactly. That can not work, we always need to do the coldplug in the
rootfs, because only there are all the tools we require.

With the automatic devtmpfs mount in the rootfs, we can do most of the
coldplug in the background, because other stuff can be sure that
mandatory device nodes already exist, and they do not need to wait for
udev to finish.

Inside the initramfs, the need for coldplug is very much limited to
module loading and block device handling, and has also no hard
checkpoint anymore, when devtmpfsl pre-populates /dev.

Static /dev entries are no option anymore, with all the dynamic number
assignments today. It might be fine for custom systems, but distros
can not use it at all. And even for the custom setups, which could do
it, devtmpfs should be the most flexible and reliable option.

I think the init=/bin/sh case alone would be worth to do it, without
any of the other optimizations it makes possible. It's a pretty
difficult to manage situation today, if your userspace breaks, and you
need to get to your devices, and /dev is empty, contains entries with
the wrong numbers, or does not contain what you are looking for.

Thanks,
Kay