linux-kernel - Re: Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by default

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]

Message-ID: <ac3eb2511001160751g2357bf2en2bfacaabe5c2f7e@mail.gmail.com>
Date:	Sat, 16 Jan 2010 16:51:23 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Greg KH <greg@...ah.com>, Arjan van de Ven <arjan@...radead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by 
	default

On Fri, Jan 15, 2010 at 21:57, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> Why?  All major distros need this at boot time, and as we have been
>
> No they don't.
>
> Centos doesn't (in fact I suspect it'll break)
> Fedora 11 doesn't
> Fedora 12 doesn't seem to (but seems to be willing to use it)
> Ditto all the older SuSE, Ubuntu etc releases that are *still*
> active/supported/maintained

Fedora, SUSE, Ubuntu, ... All releases currently in development enable
and use it.

>> through a release cycle with the config option, anyone who is
>> incrementally updating will continue with their existing value.  But new
>> people coming in, will get the option as it is most likely required to
>> boot properly.
>>
>> Makes sense to me.
>
> That may well be true - in which case it needs to be very clearly
> documented when to enable it.

For now, the systems will bootup fine without it, but I expect over
time, it will get a requirement. Udev does not care about it, but the
boot scripts/initramfs tools will probably get trimmed down, because
there is much less to do with the kernel provided nodes, than what is
needed today to bootstrap /dev.

And it should not harm any old system if it is enabled. If initramfs
is used it's completely invisible, if a custom kernel with
kernel-mounted rootfs is used, the udev boot script usually
over-mounts the devtmpfs at /dev with an empty tmpfs, like it has
always done it before.

The only thing it should change is that we now should be able to
bootup a box without an initramfs, without manually filling /dev with
static nodes beforehand. Current distro installations do not put a
single file in /dev on the rootfs, and trying to boot a kernel without
an initramfs usually just fails without putting some nodes there in
preparation.

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/