Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
[Yes, this patch is superseded by your series starting at https://lkml.org/lkml/2015/5/14/447 . But I wanted to jot this down somewhere.] On Tue, 2015-05-12 at 00:15 +0200, Paul Bolle wrote: > On Mon, 2015-05-11 at 15:04 -0700, Josh Triplett wrote: > > On Mon, May 11, 2015 at 11:50:21PM +0200, Paul Bolle wrote: > > > On Mon, 2015-05-11 at 13:23 -0700, Josh Triplett wrote: > > > > +config KALLSYMS_ALL > > > > + bool "Include all symbols in kallsyms" > > > > > > (For some reason this entry doesn't have if EXPERT but it seems to > > > behave as expected. Odd.) > > > > Because it depends on KALLSYMS. Magic! > > Welcome to the land of Kconfig! It's even more subtle (at least currently, ie before this patch is applied). KALLSYMS_ALL's prompt doesn't depend on EXPERT. KALLSYMS's prompt does. For some reason, perhaps because KALLSYMS_ALL depends on KALLSYMS, this makes both entries visible under EXPERT's menu even if EXPERT is _not_ set. But, in contrast to BPF_SYSCALL, this doesn't influence the following symbols that do have a prompt that depends on EXPERT. Adding "if EXPERT" to the prompt of KALLSYMS_ALL does hide that symbol _and_ KALLSYMS (when EXPERT is not set, of course). (This may be documented, or clearly commented in the code. I didn't check.) > > > > + depends on DEBUG_KERNEL && KALLSYMS > > > > + help > > > > + Normally kallsyms only contains the symbols of functions for > > > > nicer > > > > + OOPS messages and backtraces (i.e., symbols from the text > > > > and inittext > > > > + sections). This is sufficient for most cases. And only in > > > > very rare > > > > + cases (e.g., when a debugger is used) all symbols are > > > > required (e.g., > > > > + names of variables from the data sections, etc). > > > > + > > > > + This option makes sure that all symbols are loaded into the > > > > kernel > > > > + image (i.e., symbols from all sections) in cost of increased > > > > kernel > > > > + size (depending on the kernel configuration, it may be > > > > 300KiB or > > > > + something like this). > > > > + > > > > + Say N unless you really need all symbols. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Tue, May 12, 2015 at 12:36:49AM +0200, Luis R. Rodriguez wrote: > On Mon, May 11, 2015 at 01:23:02PM -0700, Josh Triplett wrote: > > init/Kconfig| 232 > > +--- > > init/Kconfig.expert | 231 > > +++ > > 2 files changed, 232 insertions(+), 231 deletions(-) > > create mode 100644 init/Kconfig.expert > > I'm blinded by this patch, can you use git format-patch -M and also add: > > [diff] > > renamelimit=0 > > To your .gitconfig >From a quick test, doing what you suggest doesn't have any effect; if I also use -C1 instead of -M, then the patch to init/Kconfig looks exactly the same (deleting 231 lines and adding a "source" line), while the patch to init/Kconfig.expert goes from adding 231 lines to copying init/Kconfig and deleting 1800 lines. That does not seem like an improvement. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Tue, May 12, 2015 at 12:01:27AM +0200, Paul Bolle wrote: > On Mon, 2015-05-11 at 14:47 -0700, Josh Triplett wrote: > > On Mon, May 11, 2015 at 11:32:28PM +0200, Paul Bolle wrote: > > > Is squashing those two lines worth a new kconfig mechanism? > > > > In my opinion, yes. If you use the implicit (and error-prone) > > menuconfig submenuing, you get a single entry with the '[ ]' and the > > submenu. There are currently 272 instances of "menuconfig" in Kconfig > > files. > > How many of those use the subtle trick EXPERT uses? A rough search suggests about 35, with the rest using an "if" right after the menu (presumably because they want dependencies rather than visibility). (A couple of which currently have the same broken-menu problem today's patch 1 fixed for EXPERT, and a couple of which are using that trick *across input files*.) > > I'd like to have a less error-prone mechanism for people to use, > > with an explicit "endmenu" at the end, and I don't want to leave any > > incentive for people to need the more error-prone version. > > > > I would be tempted to just make "menuconfig" require an endmenu, and > > convert all users, but that would almost certainly break many > > third-party users of kconfig. So instead, I'm currently extending > > "menu" (which already expects "endmenu") to allow the syntax > > "menu config SYMBOL", which acts like a combination of "config SYMBOL" > > and a menu with "visible if SYMBOL". > > Bikeshedding (before I'm even convinced of the need of this extension): > "menu config" is far too similar to "menuconfig". Yeah, agreed; given that people will still end up using "menuconfig" in light of the above, I'll use another syntax. > > Diffstat for the patch I'm testing > > right now: > > > > scripts/kconfig/zconf.y | 18 ++ > > 1 file changed, 18 insertions(+) > > > > That seems worthwhile to have a less error-prone menu mechanism. > > > > (The actual patch would also need to updated zconf.tab.c_shipped.) > > And some lines in Documentation/kbuild/kconfig-language.txt (speaking > from memory). Good point; this does need documentation. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, May 11, 2015 at 01:23:02PM -0700, Josh Triplett wrote: > init/Kconfig| 232 > +--- > init/Kconfig.expert | 231 +++ > 2 files changed, 232 insertions(+), 231 deletions(-) > create mode 100644 init/Kconfig.expert I'm blinded by this patch, can you use git format-patch -M and also add: [diff] renamelimit=0 To your .gitconfig Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, 2015-05-11 at 15:04 -0700, Josh Triplett wrote: > On Mon, May 11, 2015 at 11:50:21PM +0200, Paul Bolle wrote: > > On Mon, 2015-05-11 at 13:23 -0700, Josh Triplett wrote: > > > +config KALLSYMS_ALL > > > + bool "Include all symbols in kallsyms" > > > > (For some reason this entry doesn't have if EXPERT but it seems to > > behave as expected. Odd.) > > Because it depends on KALLSYMS. Magic! Welcome to the land of Kconfig! > > > + depends on DEBUG_KERNEL && KALLSYMS > > > + help > > > +Normally kallsyms only contains the symbols of functions for nicer > > > +OOPS messages and backtraces (i.e., symbols from the text and > > > inittext > > > +sections). This is sufficient for most cases. And only in very rare > > > +cases (e.g., when a debugger is used) all symbols are required (e.g., > > > +names of variables from the data sections, etc). > > > + > > > +This option makes sure that all symbols are loaded into the kernel > > > +image (i.e., symbols from all sections) in cost of increased kernel > > > +size (depending on the kernel configuration, it may be 300KiB or > > > +something like this). > > > + > > > +Say N unless you really need all symbols. > > > + > > > +config PRINTK > > > + default y > > > + bool "Enable support for printk" if EXPERT > > > > Now you're touching this: bool [...] as the first line, please. > > I'd like the commit moving these to their own file to very obviously > look like it's moving these lines unmodified, rather than making changes > in the process. If you want this (and all the subsequent instances you > flagged) cleaned up, let's do that as a subsequent patch separate from > the move. That was one of my pet peeves leaving it's cage. Still, not sure if we'd really notice if it's not a simple move. But a separate patch would mainly add noise, so let's not do that. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, May 11, 2015 at 11:50:21PM +0200, Paul Bolle wrote: > On Mon, 2015-05-11 at 13:23 -0700, Josh Triplett wrote: > > --- /dev/null > > +++ b/init/Kconfig.expert > > @@ -0,0 +1,231 @@ > > +menuconfig EXPERT > > + bool "Configure standard kernel features (expert users)" > > + # Unhide debug options, to make the on-by-default options visible > > + select DEBUG_KERNEL > > + help > > + This option allows certain base kernel options and settings > > + to be disabled or tweaked. This is for specialized > > + environments which can tolerate a "non-standard" kernel. > > + Only use this if you really know what you are doing. > > Comment here saying > # All entries in this file must have "if EXPERT" after their prompt > > or something to that effect (pending you patch, that is)? Yeah, I should add such a comment. I was hoping to make it obsolete via kconfig changes, but in the interim, sure. > > +config KALLSYMS > > +bool "Load all symbols for debugging/ksymoops" if EXPERT > > +default y > > +help > > + Say Y here to let the kernel print out symbolic crash information and > > + symbolic stack backtraces. This increases the size of the kernel > > + somewhat, as all symbols have to be loaded into the kernel image. > > + > > +config KALLSYMS_ALL > > + bool "Include all symbols in kallsyms" > > (For some reason this entry doesn't have if EXPERT but it seems to > behave as expected. Odd.) Because it depends on KALLSYMS. Magic! > > + depends on DEBUG_KERNEL && KALLSYMS > > + help > > + Normally kallsyms only contains the symbols of functions for nicer > > + OOPS messages and backtraces (i.e., symbols from the text and > > inittext > > + sections). This is sufficient for most cases. And only in very rare > > + cases (e.g., when a debugger is used) all symbols are required (e.g., > > + names of variables from the data sections, etc). > > + > > + This option makes sure that all symbols are loaded into the kernel > > + image (i.e., symbols from all sections) in cost of increased kernel > > + size (depending on the kernel configuration, it may be 300KiB or > > + something like this). > > + > > + Say N unless you really need all symbols. > > + > > +config PRINTK > > + default y > > + bool "Enable support for printk" if EXPERT > > Now you're touching this: bool [...] as the first line, please. I'd like the commit moving these to their own file to very obviously look like it's moving these lines unmodified, rather than making changes in the process. If you want this (and all the subsequent instances you flagged) cleaned up, let's do that as a subsequent patch separate from the move. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, 2015-05-11 at 14:47 -0700, Josh Triplett wrote: > On Mon, May 11, 2015 at 11:32:28PM +0200, Paul Bolle wrote: > > Is squashing those two lines worth a new kconfig mechanism? > > In my opinion, yes. If you use the implicit (and error-prone) > menuconfig submenuing, you get a single entry with the '[ ]' and the > submenu. There are currently 272 instances of "menuconfig" in Kconfig > files. How many of those use the subtle trick EXPERT uses? > I'd like to have a less error-prone mechanism for people to use, > with an explicit "endmenu" at the end, and I don't want to leave any > incentive for people to need the more error-prone version. > > I would be tempted to just make "menuconfig" require an endmenu, and > convert all users, but that would almost certainly break many > third-party users of kconfig. So instead, I'm currently extending > "menu" (which already expects "endmenu") to allow the syntax > "menu config SYMBOL", which acts like a combination of "config SYMBOL" > and a menu with "visible if SYMBOL". Bikeshedding (before I'm even convinced of the need of this extension): "menu config" is far too similar to "menuconfig". > Diffstat for the patch I'm testing > right now: > > scripts/kconfig/zconf.y | 18 ++ > 1 file changed, 18 insertions(+) > > That seems worthwhile to have a less error-prone menu mechanism. > > (The actual patch would also need to updated zconf.tab.c_shipped.) And some lines in Documentation/kbuild/kconfig-language.txt (speaking from memory). > (Also, the diff you posted would be smaller if you left "config EXPERT" > at the top of init/Kconfig.expert; why the move?) It was a quick hack. I didn't gave the move much thought, to be honest. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, 2015-05-11 at 13:23 -0700, Josh Triplett wrote: > --- /dev/null > +++ b/init/Kconfig.expert > @@ -0,0 +1,231 @@ > +menuconfig EXPERT > + bool "Configure standard kernel features (expert users)" > + # Unhide debug options, to make the on-by-default options visible > + select DEBUG_KERNEL > + help > + This option allows certain base kernel options and settings > + to be disabled or tweaked. This is for specialized > + environments which can tolerate a "non-standard" kernel. > + Only use this if you really know what you are doing. Comment here saying # All entries in this file must have "if EXPERT" after their prompt or something to that effect (pending you patch, that is)? > +config KALLSYMS > + bool "Load all symbols for debugging/ksymoops" if EXPERT > + default y > + help > +Say Y here to let the kernel print out symbolic crash information and > +symbolic stack backtraces. This increases the size of the kernel > +somewhat, as all symbols have to be loaded into the kernel image. > + > +config KALLSYMS_ALL > + bool "Include all symbols in kallsyms" (For some reason this entry doesn't have if EXPERT but it seems to behave as expected. Odd.) > + depends on DEBUG_KERNEL && KALLSYMS > + help > +Normally kallsyms only contains the symbols of functions for nicer > +OOPS messages and backtraces (i.e., symbols from the text and > inittext > +sections). This is sufficient for most cases. And only in very rare > +cases (e.g., when a debugger is used) all symbols are required (e.g., > +names of variables from the data sections, etc). > + > +This option makes sure that all symbols are loaded into the kernel > +image (i.e., symbols from all sections) in cost of increased kernel > +size (depending on the kernel configuration, it may be 300KiB or > +something like this). > + > +Say N unless you really need all symbols. > + > +config PRINTK > + default y > + bool "Enable support for printk" if EXPERT Now you're touching this: bool [...] as the first line, please. > + select IRQ_WORK > + help > + This option enables normal printk support. Removing it > + eliminates most of the message strings from the kernel image > + and makes the kernel more or less silent. As this makes it > + very difficult to diagnose system problems, saying N here is > + strongly discouraged. > +config ELF_CORE > + depends on COREDUMP > + default y > + bool "Enable ELF core dumps" if EXPERT Ditto. > + help > + Enable support for generating core dumps. Disabling saves about 4k. > +config BASE_FULL > + default y > + bool "Enable full-sized data structures for core" if EXPERT Ditto. > + help > + Disabling this option reduces the size of miscellaneous core > + kernel data structures. This saves memory on small machines, > + but may reduce performance. > +config PCI_QUIRKS > + default y > + bool "Enable PCI quirk workarounds" if EXPERT Ditto. > + depends on PCI > + help > + This enables workarounds for various PCI chipset > + bugs/quirks. Disable this only if your target machine is > + unaffected by PCI quirks. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, May 11, 2015 at 11:32:28PM +0200, Paul Bolle wrote: > On Mon, 2015-05-11 at 14:18 -0700, Josh Triplett wrote: > > However, that would produce *two* entries under the "General setup" > > menu: a yes/no entry "Configure standard kernel features (expert users)" > > with no submenu, and a "Some separate menu prompt here" entry with a > > submenu but no '[ ]' for a yes/no option. Integrating the two (without > > using menuconfig's implicit "add stuff to submenu until an option's > > prompt doesn't depend on this symbol" magic) requires new a kconfig > > mechanism. > > The diff pasted at the end of this message, which I quickly cobbled > together an applies on top of this 2/1, generates these two lines in > menuconfig (for EXPERT = 'y') > [*] Configure standard kernel features (expert users) > Standard kernel features ---> > > Is squashing those two lines worth a new kconfig mechanism? In my opinion, yes. If you use the implicit (and error-prone) menuconfig submenuing, you get a single entry with the '[ ]' and the submenu. There are currently 272 instances of "menuconfig" in Kconfig files. I'd like to have a less error-prone mechanism for people to use, with an explicit "endmenu" at the end, and I don't want to leave any incentive for people to need the more error-prone version. I would be tempted to just make "menuconfig" require an endmenu, and convert all users, but that would almost certainly break many third-party users of kconfig. So instead, I'm currently extending "menu" (which already expects "endmenu") to allow the syntax "menu config SYMBOL", which acts like a combination of "config SYMBOL" and a menu with "visible if SYMBOL". Diffstat for the patch I'm testing right now: scripts/kconfig/zconf.y | 18 ++ 1 file changed, 18 insertions(+) That seems worthwhile to have a less error-prone menu mechanism. (The actual patch would also need to updated zconf.tab.c_shipped.) (Also, the diff you posted would be smaller if you left "config EXPERT" at the top of init/Kconfig.expert; why the move?) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, 2015-05-11 at 14:18 -0700, Josh Triplett wrote: > However, that would produce *two* entries under the "General setup" > menu: a yes/no entry "Configure standard kernel features (expert users)" > with no submenu, and a "Some separate menu prompt here" entry with a > submenu but no '[ ]' for a yes/no option. Integrating the two (without > using menuconfig's implicit "add stuff to submenu until an option's > prompt doesn't depend on this symbol" magic) requires new a kconfig > mechanism. The diff pasted at the end of this message, which I quickly cobbled together an applies on top of this 2/1, generates these two lines in menuconfig (for EXPERT = 'y') [*] Configure standard kernel features (expert users) Standard kernel features ---> Is squashing those two lines worth a new kconfig mechanism? Thanks, Paul Bolle diff --git a/init/Kconfig b/init/Kconfig index 06c585007964..dfb2a7405a83 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1421,6 +1421,16 @@ config BPF_SYSCALL Enable the bpf() system call that allows to manipulate eBPF programs and maps via file descriptors. +config EXPERT + bool "Configure standard kernel features (expert users)" + # Unhide debug options, to make the on-by-default options visible + select DEBUG_KERNEL + help + This option allows certain base kernel options and settings + to be disabled or tweaked. This is for specialized + environments which can tolerate a "non-standard" kernel. + Only use this if you really know what you are doing. + source init/Kconfig.expert config EMBEDDED diff --git a/init/Kconfig.expert b/init/Kconfig.expert index c84a3720164b..c5718f1dc978 100644 --- a/init/Kconfig.expert +++ b/init/Kconfig.expert @@ -1,22 +1,15 @@ -menuconfig EXPERT - bool "Configure standard kernel features (expert users)" - # Unhide debug options, to make the on-by-default options visible - select DEBUG_KERNEL - help - This option allows certain base kernel options and settings - to be disabled or tweaked. This is for specialized - environments which can tolerate a "non-standard" kernel. - Only use this if you really know what you are doing. +menu "Standard kernel features" + visible if EXPERT config UID16 - bool "Enable 16-bit UID system calls" if EXPERT + bool "Enable 16-bit UID system calls" depends on HAVE_UID16 && MULTIUSER default y help This enables the legacy 16-bit UID syscall wrappers. config MULTIUSER - bool "Multiple users, groups and capabilities support" if EXPERT + bool "Multiple users, groups and capabilities support" default y help This option enables support for non-root users, groups and @@ -30,7 +23,7 @@ config MULTIUSER If unsure, say Y here. config SGETMASK_SYSCALL - bool "sgetmask/ssetmask syscalls support" if EXPERT + bool "sgetmask/ssetmask syscalls support" def_bool PARISC || MN10300 || BLACKFIN || M68K || PPC || MIPS || X86 || SPARC || CRIS || MICROBLAZE || SUPERH ---help--- sys_sgetmask and sys_ssetmask are obsolete system calls @@ -40,7 +33,7 @@ config SGETMASK_SYSCALL If unsure, leave the default option here. config SYSFS_SYSCALL - bool "Sysfs syscall support" if EXPERT + bool "Sysfs syscall support" default y ---help--- sys_sysfs is an obsolete system call no longer supported in libc. @@ -50,7 +43,7 @@ config SYSFS_SYSCALL If unsure say Y here. config SYSCTL_SYSCALL - bool "Sysctl syscall support" if EXPERT + bool "Sysctl syscall support" depends on PROC_SYSCTL default n select SYSCTL @@ -67,7 +60,7 @@ config SYSCTL_SYSCALL If unsure say N here. config KALLSYMS -bool "Load all symbols for debugging/ksymoops" if EXPERT +bool "Load all symbols for debugging/ksymoops" default y help Say Y here to let the kernel print out symbolic crash information and @@ -93,7 +86,7 @@ config KALLSYMS_ALL config PRINTK default y - bool "Enable support for printk" if EXPERT + bool "Enable support for printk" select IRQ_WORK help This option enables normal printk support. Removing it @@ -103,7 +96,7 @@ config PRINTK strongly discouraged. config BUG - bool "BUG() support" if EXPERT + bool "BUG() support" default y help Disabling this option eliminates support for BUG and WARN, reducing @@ -115,13 +108,13 @@ config BUG config ELF_CORE depends on COREDUMP default y - bool "Enable ELF core dumps" if EXPERT + bool "Enable ELF core dumps" help Enable support for generating core dumps. Disabling saves about 4k. config PCSPKR_PLATFORM - bool "En
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, May 11, 2015 at 11:01:22PM +0200, Paul Bolle wrote: > On Mon, 2015-05-11 at 13:23 -0700, Josh Triplett wrote: > > I'd also like to factor the "if EXPERT" off of all the prompts and into a > > single scoped item wrapped around all of them, but kconfig doesn't have any > > way > > to do that. "menuconfig" is just a hint, with no matching "endmenu" and no > > implicit visibility; "menu" is scoped and has "visible if", but that would > > create a separate option containing a menu, rather than a menu under > > EXPERT's > > "Configure standard kernel features (expert users)". And "if EXPERT ... > > endif" > > produces a dependency, not a prompt-visibility condition. So I think this > > would require changes to the Kconfig language, to introduce either a scoped > > "visible if EXPERT ... endvisible" or similar, or a scoped version of > > menuconfig with a matching "endmenu" and implicit visibility (effectively a > > "menu" statement with attached "config" rather than a "config" with a hint > > "this might be a menu"). I'm leaning towards the latter. > > The behavior of menuconfig in this case is rather subtle. I must admit I > never noticed it. > > The "visible" option to menus is little used, and I'm not really > familiar with it. So, for what it's worth: would adding a new menu with > visible if EXPERT > > attached to it, and putting all current > prompt "Foo" if EXPERT > > entries in that menu roughly do what you want? Not quite. menu has a prompt but no associated symbol, so with current kconfig that would look like: config EXPERT bool "Configure standard kernel features (expert users)" ... menu "Some separate menu prompt here" visible if EXPERT ... various options that currently have if EXPERT on their prompts ... endmenu However, that would produce *two* entries under the "General setup" menu: a yes/no entry "Configure standard kernel features (expert users)" with no submenu, and a "Some separate menu prompt here" entry with a submenu but no '[ ]' for a yes/no option. Integrating the two (without using menuconfig's implicit "add stuff to submenu until an option's prompt doesn't depend on this symbol" magic) requires new a kconfig mechanism. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
On Mon, 2015-05-11 at 13:23 -0700, Josh Triplett wrote: > I'd also like to factor the "if EXPERT" off of all the prompts and into a > single scoped item wrapped around all of them, but kconfig doesn't have any > way > to do that. "menuconfig" is just a hint, with no matching "endmenu" and no > implicit visibility; "menu" is scoped and has "visible if", but that would > create a separate option containing a menu, rather than a menu under EXPERT's > "Configure standard kernel features (expert users)". And "if EXPERT ... > endif" > produces a dependency, not a prompt-visibility condition. So I think this > would require changes to the Kconfig language, to introduce either a scoped > "visible if EXPERT ... endvisible" or similar, or a scoped version of > menuconfig with a matching "endmenu" and implicit visibility (effectively a > "menu" statement with attached "config" rather than a "config" with a hint > "this might be a menu"). I'm leaning towards the latter. The behavior of menuconfig in this case is rather subtle. I must admit I never noticed it. The "visible" option to menus is little used, and I'm not really familiar with it. So, for what it's worth: would adding a new menu with visible if EXPERT attached to it, and putting all current prompt "Foo" if EXPERT entries in that menu roughly do what you want? > So I'll send a followup patch enhancing kconfig to improve this case, > but I think splitting this into a separate file is still worth it even > without that. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
The expert menu frequently gets broken by a config item in the middle that leaves off the "if EXPERT" from its prompt. This results in the remainder of the menu spilling out into the parent "General setup" menu. Move the entire expert menu into a separate Kconfig file, init/Kconfig.expert, to make this harder to do accidentally, and to break up the exceedingly long init/Kconfig a bit. Signed-off-by: Josh Triplett --- This applies on top of "init/Kconfig: Fix break in middle of EXPERT menu". Please apply both. I'd also like to factor the "if EXPERT" off of all the prompts and into a single scoped item wrapped around all of them, but kconfig doesn't have any way to do that. "menuconfig" is just a hint, with no matching "endmenu" and no implicit visibility; "menu" is scoped and has "visible if", but that would create a separate option containing a menu, rather than a menu under EXPERT's "Configure standard kernel features (expert users)". And "if EXPERT ... endif" produces a dependency, not a prompt-visibility condition. So I think this would require changes to the Kconfig language, to introduce either a scoped "visible if EXPERT ... endvisible" or similar, or a scoped version of menuconfig with a matching "endmenu" and implicit visibility (effectively a "menu" statement with attached "config" rather than a "config" with a hint "this might be a menu"). I'm leaning towards the latter. So I'll send a followup patch enhancing kconfig to improve this case, but I think splitting this into a separate file is still worth it even without that. init/Kconfig| 232 +--- init/Kconfig.expert | 231 +++ 2 files changed, 232 insertions(+), 231 deletions(-) create mode 100644 init/Kconfig.expert diff --git a/init/Kconfig b/init/Kconfig index e2f16f1..a2de3f5 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1351,237 +1351,7 @@ config BPF_SYSCALL Enable the bpf() system call that allows to manipulate eBPF programs and maps via file descriptors. -menuconfig EXPERT - bool "Configure standard kernel features (expert users)" - # Unhide debug options, to make the on-by-default options visible - select DEBUG_KERNEL - help - This option allows certain base kernel options and settings - to be disabled or tweaked. This is for specialized - environments which can tolerate a "non-standard" kernel. - Only use this if you really know what you are doing. - -config UID16 - bool "Enable 16-bit UID system calls" if EXPERT - depends on HAVE_UID16 && MULTIUSER - default y - help - This enables the legacy 16-bit UID syscall wrappers. - -config MULTIUSER - bool "Multiple users, groups and capabilities support" if EXPERT - default y - help - This option enables support for non-root users, groups and - capabilities. - - If you say N here, all processes will run with UID 0, GID 0, and all - possible capabilities. Saying N here also compiles out support for - system calls related to UIDs, GIDs, and capabilities, such as setuid, - setgid, and capset. - - If unsure, say Y here. - -config SGETMASK_SYSCALL - bool "sgetmask/ssetmask syscalls support" if EXPERT - def_bool PARISC || MN10300 || BLACKFIN || M68K || PPC || MIPS || X86 || SPARC || CRIS || MICROBLAZE || SUPERH - ---help--- - sys_sgetmask and sys_ssetmask are obsolete system calls - no longer supported in libc but still enabled by default in some - architectures. - - If unsure, leave the default option here. - -config SYSFS_SYSCALL - bool "Sysfs syscall support" if EXPERT - default y - ---help--- - sys_sysfs is an obsolete system call no longer supported in libc. - Note that disabling this option is more secure but might break - compatibility with some systems. - - If unsure say Y here. - -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 - to properly maintain and use. The interface in /proc/sys - using paths with ascii names is now the primary path to this - information. - - Almost nothing using the binary sysctl interface so if you are - trying to save some space it is probably safe to disable this, - making your kernel marginally smaller. - - If unsure say N here. - -config KALLSYMS -bool "Load all symbols for debugging/ksymoops" if EXPERT -default y -help - Say Y here to let the kernel print out symbolic crash information and - symbolic stack backtraces. This increases the size of the kernel - somewhat, as a
