[PATCH] Kconfig: drop bogus default values

[PATCH] Kconfig: drop bogus default values

[Jan Beulich]

Default "no" is pretty pointless for options without (visible) prompts:
They only clutter .config-s with "# CONFIG_... is not set" and thus
prevent users of "make oldconfig", when the option obtains a prompt or
its prompt becomes visible, noticing that these may now be enabled.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 arch/Kconfig   |    7 ++++---
 init/Kconfig   |   10 ++++------
 lib/Kconfig    |    3 +--
 lib/xz/Kconfig |    1 -
 4 files changed, 9 insertions(+), 12 deletions(-)

--- 4.0-rc3/arch/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/arch/Kconfig
@@ -86,7 +86,7 @@ config KPROBES_ON_FTRACE
 	 optimize on top of function tracing.
 
 config UPROBES
-	def_bool n
+	bool
 	select PERCPU_RWSEM
 	help
 	  Uprobes is the user-space counterpart to kprobes: they
@@ -100,7 +100,8 @@ config UPROBES
 	    application. )
 
 config HAVE_64BIT_ALIGNED_ACCESS
-	def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
+	bool
+	default y if 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
 	help
 	  Some architectures require 64 bit accesses to be 64 bit
 	  aligned, which also requires structs containing 64 bit values
@@ -352,7 +353,7 @@ config HAVE_CC_STACKPROTECTOR
 	  - it has implemented a stack canary (e.g. __stack_chk_guard)
 
 config CC_STACKPROTECTOR
-	def_bool n
+	bool
 	help
 	  Set when a stack-protector mode is enabled, so that the build
 	  can enable kernel-side support for the GCC feature.
--- 4.0-rc3/init/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/init/Kconfig
@@ -518,7 +518,8 @@ config TASKS_RCU
 	  If unsure, say N.
 
 config RCU_STALL_COMMON
-	def_bool ( TREE_RCU || PREEMPT_RCU || RCU_TRACE )
+	def_bool y
+	depends on TREE_RCU || PREEMPT_RCU || RCU_TRACE
 	help
 	  This option enables RCU CPU stall code that is common between
 	  the TINY and TREE variants of RCU.  The purpose is to allow
@@ -652,7 +653,8 @@ config RCU_FAST_NO_HZ
 	  Say N if you are unsure.
 
 config TREE_RCU_TRACE
-	def_bool RCU_TRACE && ( TREE_RCU || PREEMPT_RCU )
+	def_bool y
+	depends on RCU_TRACE && (TREE_RCU || PREEMPT_RCU)
 	select DEBUG_FS
 	help
 	  This option provides tracing for the TREE_RCU and
@@ -795,7 +797,6 @@ endmenu # "RCU Subsystem"
 
 config BUILD_BIN2C
 	bool
-	default n
 
 config IKCONFIG
 	tristate "Kernel .config support"
@@ -1136,7 +1137,6 @@ endif # CGROUPS
 
 config CHECKPOINT_RESTORE
 	bool "Checkpoint/restore support" if EXPERT
-	default n
 	help
 	  Enables additional kernel features in a sake of checkpoint/restore.
 	  In particular it adds auxiliary prctl codes to setup process text,
@@ -1371,7 +1371,6 @@ config SYSFS_SYSCALL
 config SYSCTL_SYSCALL
 	bool "Sysctl syscall support" if EXPERT
 	depends on PROC_SYSCTL
-	default n
 	select SYSCTL
 	---help---
 	  sys_sysctl uses binary paths that have been found challenging
@@ -1753,7 +1752,6 @@ endmenu		# General setup
 
 config HAVE_GENERIC_DMA_COHERENT
 	bool
-	default n
 
 config SLABINFO
 	bool
--- 4.0-rc3/lib/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/lib/Kconfig
@@ -3,7 +3,7 @@
 #
 
 config BINARY_PRINTF
-	def_bool n
+	bool
 
 menu "Library routines"
 
@@ -49,7 +49,6 @@ config GENERIC_IOMAP
 
 config GENERIC_IO
 	bool
-	default n
 
 config STMP_DEVICE
 	bool
--- 4.0-rc3/lib/xz/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/lib/xz/Kconfig
@@ -42,7 +42,6 @@ endif
 
 config XZ_DEC_BCJ
 	bool
-	default n
 
 config XZ_DEC_TEST
 	tristate "XZ decompressor tester"

[PATCH] Kconfig: drop bogus default values

[Jan Beulich]

Default "no" is pretty pointless for options without (visible) prompts:
They only clutter .config-s with "# CONFIG_... is not set" and thus
prevent users of "make oldconfig", when the option obtains a prompt or
its prompt becomes visible, noticing that these may now be enabled.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
 arch/Kconfig   |    7 ++++---
 init/Kconfig   |   10 ++++------
 lib/Kconfig    |    3 +--
 lib/xz/Kconfig |    1 -
 4 files changed, 9 insertions(+), 12 deletions(-)

--- 4.0-rc3/arch/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/arch/Kconfig
@@ -86,7 +86,7 @@ config KPROBES_ON_FTRACE
 	 optimize on top of function tracing.
 
 config UPROBES
-	def_bool n
+	bool
 	select PERCPU_RWSEM
 	help
 	  Uprobes is the user-space counterpart to kprobes: they
@@ -100,7 +100,8 @@ config UPROBES
 	    application. )
 
 config HAVE_64BIT_ALIGNED_ACCESS
-	def_bool 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
+	bool
+	default y if 64BIT && !HAVE_EFFICIENT_UNALIGNED_ACCESS
 	help
 	  Some architectures require 64 bit accesses to be 64 bit
 	  aligned, which also requires structs containing 64 bit values
@@ -352,7 +353,7 @@ config HAVE_CC_STACKPROTECTOR
 	  - it has implemented a stack canary (e.g. __stack_chk_guard)
 
 config CC_STACKPROTECTOR
-	def_bool n
+	bool
 	help
 	  Set when a stack-protector mode is enabled, so that the build
 	  can enable kernel-side support for the GCC feature.
--- 4.0-rc3/init/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/init/Kconfig
@@ -518,7 +518,8 @@ config TASKS_RCU
 	  If unsure, say N.
 
 config RCU_STALL_COMMON
-	def_bool ( TREE_RCU || PREEMPT_RCU || RCU_TRACE )
+	def_bool y
+	depends on TREE_RCU || PREEMPT_RCU || RCU_TRACE
 	help
 	  This option enables RCU CPU stall code that is common between
 	  the TINY and TREE variants of RCU.  The purpose is to allow
@@ -652,7 +653,8 @@ config RCU_FAST_NO_HZ
 	  Say N if you are unsure.
 
 config TREE_RCU_TRACE
-	def_bool RCU_TRACE && ( TREE_RCU || PREEMPT_RCU )
+	def_bool y
+	depends on RCU_TRACE && (TREE_RCU || PREEMPT_RCU)
 	select DEBUG_FS
 	help
 	  This option provides tracing for the TREE_RCU and
@@ -795,7 +797,6 @@ endmenu # "RCU Subsystem"
 
 config BUILD_BIN2C
 	bool
-	default n
 
 config IKCONFIG
 	tristate "Kernel .config support"
@@ -1136,7 +1137,6 @@ endif # CGROUPS
 
 config CHECKPOINT_RESTORE
 	bool "Checkpoint/restore support" if EXPERT
-	default n
 	help
 	  Enables additional kernel features in a sake of checkpoint/restore.
 	  In particular it adds auxiliary prctl codes to setup process text,
@@ -1371,7 +1371,6 @@ config SYSFS_SYSCALL
 config SYSCTL_SYSCALL
 	bool "Sysctl syscall support" if EXPERT
 	depends on PROC_SYSCTL
-	default n
 	select SYSCTL
 	---help---
 	  sys_sysctl uses binary paths that have been found challenging
@@ -1753,7 +1752,6 @@ endmenu		# General setup
 
 config HAVE_GENERIC_DMA_COHERENT
 	bool
-	default n
 
 config SLABINFO
 	bool
--- 4.0-rc3/lib/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/lib/Kconfig
@@ -3,7 +3,7 @@
 #
 
 config BINARY_PRINTF
-	def_bool n
+	bool
 
 menu "Library routines"
 
@@ -49,7 +49,6 @@ config GENERIC_IOMAP
 
 config GENERIC_IO
 	bool
-	default n
 
 config STMP_DEVICE
 	bool
--- 4.0-rc3/lib/xz/Kconfig
+++ 4.0-rc3-Kconfig-cleanup/lib/xz/Kconfig
@@ -42,7 +42,6 @@ endif
 
 config XZ_DEC_BCJ
 	bool
-	default n
 
 config XZ_DEC_TEST
 	tristate "XZ decompressor tester"

Re: [PATCH] Kconfig: drop bogus default values

[Paul Bolle]

[Removed Yann.]

On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
> Default "no" is pretty pointless for options without (visible) prompts:

Related: is there ever a situation where using "default n" or "def_bool
n" makes sense (whether or not the entry has a prompt)? I think I once
thought of one but I can't remember it at all, so I guess my memory is
fooling me.

> They only clutter .config-s with "# CONFIG_... is not set" and thus

As far as I can see the main effect of using "default n" is that this
line will be printed. 

> prevent users of "make oldconfig", when the option obtains a prompt or
> its prompt becomes visible, noticing that these may now be enabled.

This side effect doesn't look like a feature. I scanned the source a bit
but - as usual - didn't stumble on a comment that might explain this
behavior. Michal probably feels better at home in the code and might be
able to offer a rationale.


Paul Bolle

Re: [PATCH] Kconfig: drop bogus default values

[Jan Beulich]

>>> On 12.03.15 at 13:11, <pebolle@tiscali.nl> wrote:
> On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
>> Default "no" is pretty pointless for options without (visible) prompts:
> 
> Related: is there ever a situation where using "default n" or "def_bool
> n" makes sense (whether or not the entry has a prompt)? I think I once
> thought of one but I can't remember it at all, so I guess my memory is
> fooling me.

I can't see any, but since as long as there is a visible prompt this
doesn't have any other bad effect than bloating the Kconfig file
and making its parsing a tiny bit slower, I don't care that much
about those (originally I had started a patch removing those too,
but gave up after a while).

Jan

Re: [PATCH] Kconfig: drop bogus default values

[Jan Beulich]

>>> On 12.03.15 at 13:11, <pebolle@tiscali.nl> wrote:
> On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
>> Default "no" is pretty pointless for options without (visible) prompts:
> 
> Related: is there ever a situation where using "default n" or "def_bool
> n" makes sense (whether or not the entry has a prompt)? I think I once
> thought of one but I can't remember it at all, so I guess my memory is
> fooling me.

I can't see any, but since as long as there is a visible prompt this
doesn't have any other bad effect than bloating the Kconfig file
and making its parsing a tiny bit slower, I don't care that much
about those (originally I had started a patch removing those too,
but gave up after a while).

Jan

Re: [PATCH] Kconfig: drop bogus default values

[Paul Bolle]

On Thu, 2015-03-12 at 12:36 +0000, Jan Beulich wrote:
> >>> On 12.03.15 at 13:11, <pebolle@tiscali.nl> wrote:
> > On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
> >> Default "no" is pretty pointless for options without (visible) prompts:
> > 
> > Related: is there ever a situation where using "default n" or "def_bool
> > n" makes sense (whether or not the entry has a prompt)? I think I once
> > thought of one but I can't remember it at all, so I guess my memory is
> > fooling me.
> 
> I can't see any, but since as long as there is a visible prompt this
> doesn't have any other bad effect than bloating the Kconfig file
> and making its parsing a tiny bit slower, I don't care that much
> about those (originally I had started a patch removing those too,
> but gave up after a while).

Well, unless someone comes up with a valid reason to add "default
n" (and, again, I don't think what you ran into is a valid reason) we
might instead bloat checkpatch.pl a bit by adding a warning for it. That
should at least stop new instances from being added.

I wonder whether Michal knows of a valid reason to use "default n"? What
are Jan and I missing here?


Paul Bolle

Re: [PATCH] Kconfig: drop bogus default values

[Sam Ravnborg]

On Thu, Mar 12, 2015 at 01:41:53PM +0100, Paul Bolle wrote:
> On Thu, 2015-03-12 at 12:36 +0000, Jan Beulich wrote:
> > >>> On 12.03.15 at 13:11, <pebolle@tiscali.nl> wrote:
> > > On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
> > >> Default "no" is pretty pointless for options without (visible) prompts:
> > > 
> > > Related: is there ever a situation where using "default n" or "def_bool
> > > n" makes sense (whether or not the entry has a prompt)? I think I once
> > > thought of one but I can't remember it at all, so I guess my memory is
> > > fooling me.
> > 
> > I can't see any, but since as long as there is a visible prompt this
> > doesn't have any other bad effect than bloating the Kconfig file
> > and making its parsing a tiny bit slower, I don't care that much
> > about those (originally I had started a patch removing those too,
> > but gave up after a while).
> 
> Well, unless someone comes up with a valid reason to add "default
> n" (and, again, I don't think what you ran into is a valid reason) we
> might instead bloat checkpatch.pl a bit by adding a warning for it. That
> should at least stop new instances from being added.
> 
> I wonder whether Michal knows of a valid reason to use "default n"? What
> are Jan and I missing here?
I for one cannot figure out a reason right now.
And if we want a warning then kconfig could be extended to
warn on this case - this is better than checkpatch.
This mandates that all existing uses are fixed first so we do not
see a tons of warnings in existing code.
But that should be a boring but trivial thing to do when the warning
is in place.

	Sam

Re: [PATCH] Kconfig: drop bogus default values

[Martin Walch]

On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
> On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
> > Default "no" is pretty pointless for options without (visible) prompts:
> 
> Related: is there ever a situation where using "default n" or "def_bool
> n" makes sense (whether or not the entry has a prompt)? I think I once
> thought of one but I can't remember it at all, so I guess my memory is
> fooling me.

Your memory is right. It is rarely used, but there is an application for
using a plain "default n": to overwrite an existing other default value.
Particularly in one special case this is desired: Let us say there is a
symbol that may lack a visible prompt, but has the default value y set in
a Kconfig file that is used across all architectures. If there is a single
architecture that must have the default value n then it is possible to
override the default y in the global file with a default n in the
architecture specific file.

A real world case is PCI_QUIRKS in the mainline kernel:

init/Kconfig:1554:	default y
arch/s390/Kconfig:59:	def_bool n

When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
except on s390 where PCI_QUIRKS=n.

Regards,
Martin Walch
-- 

Re: [PATCH] Kconfig: drop bogus default values

[Paul Bolle]

Hi Martin,

On Mon, 2015-03-23 at 22:08 +0100, Martin Walch wrote:
> On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
> Your memory is right.

That's nice to hear, but I'm pretty sure this never occurred to me.

> It is rarely used, but there is an application for
> using a plain "default n": to overwrite an existing other default value.
> Particularly in one special case this is desired: Let us say there is a
> symbol that may lack a visible prompt, but has the default value y set in
> a Kconfig file that is used across all architectures. If there is a single
> architecture that must have the default value n then it is possible to
> override the default y in the global file with a default n in the
> architecture specific file.
> 
> A real world case is PCI_QUIRKS in the mainline kernel:
> 
> init/Kconfig:1554:	default y
> arch/s390/Kconfig:59:	def_bool n
> 
> When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
> except on s390 where PCI_QUIRKS=n.

Good catch!

For the same effect, would it do to have
    config PCI_QUIRKS
        default y if !S390
        [...]

in init/Kconfig?


Paul Bolle

Re: [PATCH] Kconfig: drop bogus default values

[Martin Walch]

On Monday 23 March 2015 22:24:28 Paul Bolle wrote:
> > A real world case is PCI_QUIRKS in the mainline kernel:
> > 
> > init/Kconfig:1554:	default y
> > arch/s390/Kconfig:59:	def_bool n
> > 
> > When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
> > except on s390 where PCI_QUIRKS=n.
> 
> Good catch!
> 
> For the same effect, would it do to have
>     config PCI_QUIRKS
>         default y if !S390
>         [...]
> 
> in init/Kconfig?

Basically yes (although I suppose the maintainer had a good reason for
writing it the way it is now). But in the case with "def_bool n" in
arch/s390/Kconfig, the default value is explicitly set to n, while
"default y if !S390" does not set the value at all. As long as there are no
further default lines for PCI_QUIRKS below, this leads to the same
configuration. However if there was a third default line, then in the former
case that third default value would be always ignored while in the latter
case it would determine the default value on s390.

Regards,
Martin Walch
-- 

Re: [PATCH] Kconfig: drop bogus default values

[Jan Beulich]

>>> On 23.03.15 at 22:08, <walch.martin@web.de> wrote:
> On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
>> On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
>> > Default "no" is pretty pointless for options without (visible) prompts:
>> 
>> Related: is there ever a situation where using "default n" or "def_bool
>> n" makes sense (whether or not the entry has a prompt)? I think I once
>> thought of one but I can't remember it at all, so I guess my memory is
>> fooling me.
> 
> Your memory is right. It is rarely used, but there is an application for
> using a plain "default n": to overwrite an existing other default value.
> Particularly in one special case this is desired: Let us say there is a
> symbol that may lack a visible prompt, but has the default value y set in
> a Kconfig file that is used across all architectures. If there is a single
> architecture that must have the default value n then it is possible to
> override the default y in the global file with a default n in the
> architecture specific file.
> 
> A real world case is PCI_QUIRKS in the mainline kernel:
> 
> init/Kconfig:1554:	default y
> arch/s390/Kconfig:59:	def_bool n
> 
> When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
> except on s390 where PCI_QUIRKS=n.

But iirc such redundant defaults yield warnings (or at least at
some point in the past they did).

Jan

Re: [PATCH] Kconfig: drop bogus default values

[Jan Beulich]

>>> On 23.03.15 at 22:08, <walch.martin@web.de> wrote:
> On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
>> On Wed, 2015-03-11 at 13:59 +0000, Jan Beulich wrote:
>> > Default "no" is pretty pointless for options without (visible) prompts:
>> 
>> Related: is there ever a situation where using "default n" or "def_bool
>> n" makes sense (whether or not the entry has a prompt)? I think I once
>> thought of one but I can't remember it at all, so I guess my memory is
>> fooling me.
> 
> Your memory is right. It is rarely used, but there is an application for
> using a plain "default n": to overwrite an existing other default value.
> Particularly in one special case this is desired: Let us say there is a
> symbol that may lack a visible prompt, but has the default value y set in
> a Kconfig file that is used across all architectures. If there is a single
> architecture that must have the default value n then it is possible to
> override the default y in the global file with a default n in the
> architecture specific file.
> 
> A real world case is PCI_QUIRKS in the mainline kernel:
> 
> init/Kconfig:1554:	default y
> arch/s390/Kconfig:59:	def_bool n
> 
> When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
> except on s390 where PCI_QUIRKS=n.

But iirc such redundant defaults yield warnings (or at least at
some point in the past they did).

Jan

Re: [PATCH] Kconfig: drop bogus default values

[Jan Beulich]

>>> On 23.03.15 at 23:58, <walch.martin@web.de> wrote:
> On Monday 23 March 2015 22:24:28 Paul Bolle wrote:
>> > A real world case is PCI_QUIRKS in the mainline kernel:
>> > 
>> > init/Kconfig:1554:	default y
>> > arch/s390/Kconfig:59:	def_bool n
>> > 
>> > When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
>> > except on s390 where PCI_QUIRKS=n.
>> 
>> Good catch!
>> 
>> For the same effect, would it do to have
>>     config PCI_QUIRKS
>>         default y if !S390
>>         [...]
>> 
>> in init/Kconfig?
> 
> Basically yes (although I suppose the maintainer had a good reason for
> writing it the way it is now). But in the case with "def_bool n" in
> arch/s390/Kconfig, the default value is explicitly set to n, while
> "default y if !S390" does not set the value at all. As long as there are no
> further default lines for PCI_QUIRKS below, this leads to the same
> configuration. However if there was a third default line, then in the former
> case that third default value would be always ignored while in the latter
> case it would determine the default value on s390.

If the "n" default was really needed, it could be

config PCI_QUIRKS
         default !S390

Jan

Re: [PATCH] Kconfig: drop bogus default values

[Jan Beulich]

>>> On 23.03.15 at 23:58, <walch.martin@web.de> wrote:
> On Monday 23 March 2015 22:24:28 Paul Bolle wrote:
>> > A real world case is PCI_QUIRKS in the mainline kernel:
>> > 
>> > init/Kconfig:1554:	default y
>> > arch/s390/Kconfig:59:	def_bool n
>> > 
>> > When setting PCI!=n && EXPERT=n then on each architecture PCI_QUIRKS=y
>> > except on s390 where PCI_QUIRKS=n.
>> 
>> Good catch!
>> 
>> For the same effect, would it do to have
>>     config PCI_QUIRKS
>>         default y if !S390
>>         [...]
>> 
>> in init/Kconfig?
> 
> Basically yes (although I suppose the maintainer had a good reason for
> writing it the way it is now). But in the case with "def_bool n" in
> arch/s390/Kconfig, the default value is explicitly set to n, while
> "default y if !S390" does not set the value at all. As long as there are no
> further default lines for PCI_QUIRKS below, this leads to the same
> configuration. However if there was a third default line, then in the former
> case that third default value would be always ignored while in the latter
> case it would determine the default value on s390.

If the "n" default was really needed, it could be

config PCI_QUIRKS
         default !S390

Jan