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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 May 2009 16:55:38 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

On Fri, May 1, 2009 at 14:38, Alan Jenkins
<sourcejedi.lkml@...glemail.com> wrote:
> On 5/1/09, Kay Sievers <kay.sievers@...y.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/