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

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

[Kay Sievers]

From: Kay Sievers <kay.sievers@vrfy.org>
Subject: Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by default

All major distros enable devtmpfs on recent systems, so remove
the EXPERIMENTAL flag, and enable it by default to reflect how it
is used today.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
 drivers/base/Kconfig |   45 ++++++++++++++++++++++++++++-----------------
 1 file changed, 28 insertions(+), 17 deletions(-)

--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -9,29 +9,40 @@ config UEVENT_HELPER_PATH
 	  every uevent.
 
 config DEVTMPFS
-	bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
+	bool "Maintain a devtmpfs filesystem to mount at /dev"
 	depends on HOTPLUG && SHMEM && TMPFS
+	default y
 	help
-	  This creates a tmpfs filesystem, and mounts it at bootup
-	  and mounts it at /dev. The kernel driver core creates device
-	  nodes for all registered devices in that filesystem. All device
-	  nodes are owned by root and have the default mode of 0600.
-	  Userspace can add and delete the nodes as needed. This is
-	  intended to simplify bootup, and make it possible to delay
-	  the initial coldplug at bootup done by udev in userspace.
-	  It should also provide a simpler way for rescue systems
-	  to bring up a kernel with dynamic major/minor numbers.
-	  Meaningful symlinks, permissions and device ownership must
-	  still be handled by userspace.
-	  If unsure, say N here.
+	  This creates a tmpfs filesystem instance early at bootup.
+	  In this filesystem, the kernel driver core maintains device
+	  nodes with their default names and permissions for all
+	  registered devices with an assigned major/minor number.
+	  Userspace can modify the filesystem content as needed, add
+	  symlinks, and apply needed permissions.
+	  It provides a fully functional /dev directory, where usually
+	  udev runs on top, managing permissions and adding meaningful
+	  symlinks.
+	  In very limited environments, it may provide a sufficient
+	  functional /dev without any further help. It also allows simple
+	  rescue systems, and reliably handles dynamic major/minor numbers.
+	  If unsure, say Y here.
 
 config DEVTMPFS_MOUNT
-	bool "Automount devtmpfs at /dev"
+	bool "Automount devtmpfs at /dev, after the kernel mouted the rootfs"
 	depends on DEVTMPFS
+	default y
 	help
-	  This will mount devtmpfs at /dev if the kernel mounts the root
-	  filesystem. It will not affect initramfs based mounting.
-	  If unsure, say N here.
+	  This will instruct the kernel to automatically mount the
+	  devtmpfs filesystem at /dev, directly after the kernel has
+	  mounted the root filesystem. The behavior can be overridden
+	  with the commandline parameter: devtmpfs.mount=0|1.
+	  This option does not affect initramfs based booting, here
+	  the devtmpfs filesystem always needs to be mouted manually
+	  after the roots is mounted.
+	  With this option enabled, it allows to bring up a system in
+	  rescue mode with init=/bin/sh, even when the /dev directory
+	  on the rootfs is completely empty.
+	  If unsure, say Y here.
 
 config STANDALONE
 	bool "Select only drivers that don't need compile-time external firmware" if EXPERIMENTAL

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

[Stefan Richter]

Kay Sievers wrote:
>  config DEVTMPFS_MOUNT
> -	bool "Automount devtmpfs at /dev"
> +	bool "Automount devtmpfs at /dev, after the kernel mouted the rootfs"

mouted -> mounted

>  	depends on DEVTMPFS
> +	default y
>  	help
> -	  This will mount devtmpfs at /dev if the kernel mounts the root
> -	  filesystem. It will not affect initramfs based mounting.
> -	  If unsure, say N here.
> +	  This will instruct the kernel to automatically mount the
> +	  devtmpfs filesystem at /dev, directly after the kernel has
> +	  mounted the root filesystem. The behavior can be overridden
> +	  with the commandline parameter: devtmpfs.mount=0|1.
> +	  This option does not affect initramfs based booting, here
> +	  the devtmpfs filesystem always needs to be mouted manually

Here too.
-- 
Stefan Richter
-=====-==-=- ---= -====
http://arcgraph.de/sr/

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

[Arjan van de Ven]

On Thu, 14 Jan 2010 22:47:57 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:

> From: Kay Sievers <kay.sievers@vrfy.org>
> Subject: Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by
> default
> 
> All major distros enable devtmpfs on recent systems, so remove
> the EXPERIMENTAL flag, and enable it by default to reflect how it
> is used today.

removing experimental is fine... but setting it by default is a bit
over the top and very inconsistent with how the 'default' option is
used.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Greg KH]

On Fri, Jan 15, 2010 at 03:08:34PM +0100, Stefan Richter wrote:
> Kay Sievers wrote:
> >  config DEVTMPFS_MOUNT
> > -	bool "Automount devtmpfs at /dev"
> > +	bool "Automount devtmpfs at /dev, after the kernel mouted the rootfs"
> 
> mouted -> mounted
> 
> >  	depends on DEVTMPFS
> > +	default y
> >  	help
> > -	  This will mount devtmpfs at /dev if the kernel mounts the root
> > -	  filesystem. It will not affect initramfs based mounting.
> > -	  If unsure, say N here.
> > +	  This will instruct the kernel to automatically mount the
> > +	  devtmpfs filesystem at /dev, directly after the kernel has
> > +	  mounted the root filesystem. The behavior can be overridden
> > +	  with the commandline parameter: devtmpfs.mount=0|1.
> > +	  This option does not affect initramfs based booting, here
> > +	  the devtmpfs filesystem always needs to be mouted manually
> 
> Here too.

Thanks for the review, I've edited the patch to include these spelling
changes.

greg k-h

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

[Greg KH]

On Fri, Jan 15, 2010 at 06:56:38AM -0800, Arjan van de Ven wrote:
> On Thu, 14 Jan 2010 22:47:57 +0100
> Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > From: Kay Sievers <kay.sievers@vrfy.org>
> > Subject: Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by
> > default
> > 
> > All major distros enable devtmpfs on recent systems, so remove
> > the EXPERIMENTAL flag, and enable it by default to reflect how it
> > is used today.
> 
> removing experimental is fine... but setting it by default is a bit
> over the top and very inconsistent with how the 'default' option is
> used.

Why?  All major distros need this at boot time, and as we have been
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.

thanks,

greg k-h

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

[Alan Cox]

> 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


> 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.

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

[Kay Sievers]

On Fri, Jan 15, 2010 at 21:57, Alan Cox <alan@lxorguk.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

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

[Alan Cox]

On Sat, 16 Jan 2010 16:51:23 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Fri, Jan 15, 2010 at 21:57, Alan Cox <alan@lxorguk.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.

Yes - in future your statement may become true (or devtmpfs get obsoleted
by the next best thing.  Thats why it needs to be documented if it is set
that way - I've no problem with it being set that way at all.

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

[Arjan van de Ven]

On Sat, 16 Jan 2010 16:51:23 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:

>  Current distro installations do not put a
> single file in /dev on the rootfs,

any distro that does that is terminally broken; the minimum needed
is /dev/console.
I guess this can be counted as a bugreport against your distro ;-)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Pavel Machek]

On Fri 2010-01-15 10:03:41, Greg KH wrote:
> On Fri, Jan 15, 2010 at 06:56:38AM -0800, Arjan van de Ven wrote:
> > On Thu, 14 Jan 2010 22:47:57 +0100
> > Kay Sievers <kay.sievers@vrfy.org> wrote:
> > 
> > > From: Kay Sievers <kay.sievers@vrfy.org>
> > > Subject: Driver-Core: devtmpfs - remove EXPERIMENTAL and enable it by
> > > default
> > > 
> > > All major distros enable devtmpfs on recent systems, so remove
> > > the EXPERIMENTAL flag, and enable it by default to reflect how it
> > > is used today.
> > 
> > removing experimental is fine... but setting it by default is a bit
> > over the top and very inconsistent with how the 'default' option is
> > used.
> 
> Why?  All major distros need this at boot time, and as we have been
> 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.

Defaults should be back-compatible. This is not... people should be
still able to skip releases when upgrading.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Arjan van de Ven]

On Fri, 15 Jan 2010 10:03:41 -0800
Greg KH <greg@kroah.com> wrote:
> > removing experimental is fine... but setting it by default is a bit
> > over the top and very inconsistent with how the 'default' option is
> > used.
> 
> Why?  

because the convention is that we use "default y" only for those things
that used to be on, and are now turned into a config option.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Kay Sievers]

On Sun, Jan 17, 2010 at 15:58, Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 15 Jan 2010 10:03:41 -0800
> Greg KH <greg@kroah.com> wrote:
>> > removing experimental is fine... but setting it by default is a bit
>> > over the top and very inconsistent with how the 'default' option is
>> > used.
>>
>> Why?
>
> because the convention is that we use "default y" only for those things
> that used to be on, and are now turned into a config option.

Oh, I never heard of such a convention. Sure, we can remove that "y",
if this is the way it should be used, not be used.

Looking at the current Kconfig files many "default y" looks more like:
"stuff that should be in a kernel to work in a common setup". I see
new functionality often switched on with that flag.

As said, I don't mind dropping that "y", if there is such a convention.

Thanks,
Kay

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

[Arjan van de Ven]

On Wed, 20 Jan 2010 18:53:49 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Sun, Jan 17, 2010 at 15:58, Arjan van de Ven <arjan@infradead.org>
> wrote:
> > On Fri, 15 Jan 2010 10:03:41 -0800
> > Greg KH <greg@kroah.com> wrote:
> >> > removing experimental is fine... but setting it by default is a
> >> > bit over the top and very inconsistent with how the 'default'
> >> > option is used.
> >>
> >> Why?
> >
> > because the convention is that we use "default y" only for those
> > things that used to be on, and are now turned into a config option.
> 
> Oh, I never heard of such a convention. Sure, we can remove that "y",
> if this is the way it should be used, not be used.

For example in (this is just the first one google found, there's been a
bunch of discussion at various times)

http://article.gmane.org/gmane.linux.kernel/706458

Linus was rather explicit:

The rule of thumb should be:

	NO NEW FEATURES SHOULD _EVER_ DEFAULT TO 'ON'!


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Greg KH]

On Wed, Jan 20, 2010 at 10:05:53PM -0800, Arjan van de Ven wrote:
> On Wed, 20 Jan 2010 18:53:49 +0100
> Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > On Sun, Jan 17, 2010 at 15:58, Arjan van de Ven <arjan@infradead.org>
> > wrote:
> > > On Fri, 15 Jan 2010 10:03:41 -0800
> > > Greg KH <greg@kroah.com> wrote:
> > >> > removing experimental is fine... but setting it by default is a
> > >> > bit over the top and very inconsistent with how the 'default'
> > >> > option is used.
> > >>
> > >> Why?
> > >
> > > because the convention is that we use "default y" only for those
> > > things that used to be on, and are now turned into a config option.
> > 
> > Oh, I never heard of such a convention. Sure, we can remove that "y",
> > if this is the way it should be used, not be used.
> 
> For example in (this is just the first one google found, there's been a
> bunch of discussion at various times)
> 
> http://article.gmane.org/gmane.linux.kernel/706458
> 
> Linus was rather explicit:
> 
> The rule of thumb should be:
> 
> 	NO NEW FEATURES SHOULD _EVER_ DEFAULT TO 'ON'!

But this is not a "new" feature, it's been around for 6+ months by the
time it hits a release.  Does this imply that we can never change
anything to 'on' in the Kconfig files?

thanks,

greg k-h