| Message ID | 5500584D02000078000688F5@mail.emea.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- 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"
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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html