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

From: Kay Sievers
Date: Sat Jan 16 2010 - 10:51:48 EST


On Fri, Jan 15, 2010 at 21:57, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/