* Why is CONFIG_VT forced on? @ 2019-12-31 0:30 Rob Landley 2019-12-31 0:36 ` Randy Dunlap ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Rob Landley @ 2019-12-31 0:30 UTC (permalink / raw) To: linux-kernel On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual terminal), but the help doesn't mention a "selects", and I didn't spot anything obvious in "find . -name 'Kconfig*' | xargs grep -rw VT". Congratulations, you've reinvented "come from". I'm mostly familiar with the kconfig plumbing from _before_ you made it turing complete: how do I navigate this? I'm guessing "stick printfs into the menuconfig binary" is the recommended next step for investigating this? Or is there a trick I'm missing? Rob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 0:30 Why is CONFIG_VT forced on? Rob Landley @ 2019-12-31 0:36 ` Randy Dunlap 2019-12-31 0:53 ` Rob Landley 2019-12-31 1:55 ` Why is CONFIG_VT forced on? Theodore Y. Ts'o 2019-12-31 2:28 ` Al Viro 2 siblings, 1 reply; 25+ messages in thread From: Randy Dunlap @ 2019-12-31 0:36 UTC (permalink / raw) To: Rob Landley, linux-kernel On 12/30/19 4:30 PM, Rob Landley wrote: > On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual > terminal), but the help doesn't mention a "selects", and I didn't spot anything > obvious in "find . -name 'Kconfig*' | xargs grep -rw VT". > > Congratulations, you've reinvented "come from". I'm mostly familiar with the > kconfig plumbing from _before_ you made it turing complete: how do I navigate this? > > I'm guessing "stick printfs into the menuconfig binary" is the recommended next > step for investigating this? Or is there a trick I'm missing? I've never had to resort to that trick. > Rob > config VT bool "Virtual terminal" if EXPERT depends on !UML select INPUT default y ^^^^^^^^^^^^^^^^^^^ That's all it takes ^^^^^^^^^^^^^^^^. Does that explain it? Maybe I don't understand the problem. -- ~Randy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 0:36 ` Randy Dunlap @ 2019-12-31 0:53 ` Rob Landley 2019-12-31 0:59 ` Randy Dunlap 0 siblings, 1 reply; 25+ messages in thread From: Rob Landley @ 2019-12-31 0:53 UTC (permalink / raw) To: Randy Dunlap, linux-kernel On 12/30/19 6:36 PM, Randy Dunlap wrote: > On 12/30/19 4:30 PM, Rob Landley wrote: >> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual >> terminal), but the help doesn't mention a "selects", and I didn't spot anything >> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT". >> >> Congratulations, you've reinvented "come from". I'm mostly familiar with the >> kconfig plumbing from _before_ you made it turing complete: how do I navigate this? >> >> I'm guessing "stick printfs into the menuconfig binary" is the recommended next >> step for investigating this? Or is there a trick I'm missing? > > I've never had to resort to that trick. > >> Rob >> > > config VT > bool "Virtual terminal" if EXPERT > depends on !UML > select INPUT > default y > ^^^^^^^^^^^^^^^^^^^ > > That's all it takes ^^^^^^^^^^^^^^^^. Try to switch it off. It won't let you, it's forced on by something else. The help doesn't say what. (That select means it's forcing CONFIG_INPUT on?) > Does that explain it? Maybe I don't understand the problem. It's possible I don't either. I can disable it when when I start from allnoconfig and then switch CONFIG_TTY on (at which point it defaults to y, but can be disabled). Rob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 0:53 ` Rob Landley @ 2019-12-31 0:59 ` Randy Dunlap 2019-12-31 1:45 ` Rob Landley 0 siblings, 1 reply; 25+ messages in thread From: Randy Dunlap @ 2019-12-31 0:59 UTC (permalink / raw) To: Rob Landley, linux-kernel On 12/30/19 4:53 PM, Rob Landley wrote: > > > On 12/30/19 6:36 PM, Randy Dunlap wrote: >> On 12/30/19 4:30 PM, Rob Landley wrote: >>> On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual >>> terminal), but the help doesn't mention a "selects", and I didn't spot anything >>> obvious in "find . -name 'Kconfig*' | xargs grep -rw VT". >>> >>> Congratulations, you've reinvented "come from". I'm mostly familiar with the >>> kconfig plumbing from _before_ you made it turing complete: how do I navigate this? >>> >>> I'm guessing "stick printfs into the menuconfig binary" is the recommended next >>> step for investigating this? Or is there a trick I'm missing? >> >> I've never had to resort to that trick. >> >>> Rob >>> >> >> config VT >> bool "Virtual terminal" if EXPERT >> depends on !UML >> select INPUT >> default y >> ^^^^^^^^^^^^^^^^^^^ >> >> That's all it takes ^^^^^^^^^^^^^^^^. > > Try to switch it off. It won't let you, it's forced on by something else. The > help doesn't say what. (That select means it's forcing CONFIG_INPUT on?) > >> Does that explain it? Maybe I don't understand the problem. > > It's possible I don't either. I can disable it when when I start from > allnoconfig and then switch CONFIG_TTY on (at which point it defaults to y, but > can be disabled). # # Character devices # CONFIG_TTY=y # CONFIG_VT is not set But first you must set/enable EXPERT. See the bool prompt. -- ~Randy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 0:59 ` Randy Dunlap @ 2019-12-31 1:45 ` Rob Landley 2019-12-31 2:00 ` Randy Dunlap 2019-12-31 2:04 ` Rob Landley 0 siblings, 2 replies; 25+ messages in thread From: Rob Landley @ 2019-12-31 1:45 UTC (permalink / raw) To: Randy Dunlap, linux-kernel On 12/30/19 6:59 PM, Randy Dunlap wrote: > # > # Character devices > # > CONFIG_TTY=y > # CONFIG_VT is not set > > But first you must set/enable EXPERT. See the bool prompt. Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the symbol, but the symbol can still be on (and displayed) when the if is false? (Why would...) Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no mention of this? Rob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 1:45 ` Rob Landley @ 2019-12-31 2:00 ` Randy Dunlap 2019-12-31 2:04 ` Rob Landley 1 sibling, 0 replies; 25+ messages in thread From: Randy Dunlap @ 2019-12-31 2:00 UTC (permalink / raw) To: Rob Landley, linux-kernel On 12/30/19 5:45 PM, Rob Landley wrote: > On 12/30/19 6:59 PM, Randy Dunlap wrote: >> # >> # Character devices >> # >> CONFIG_TTY=y >> # CONFIG_VT is not set >> >> But first you must set/enable EXPERT. See the bool prompt. > > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the > symbol, but the symbol can still be on (and displayed) when the if is false? Yes, displayed but not edited. > (Why would...) > > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no > mention of this? Hm, it's disappointing that EXPERT is not mentioned there somewhere, when using menuconfig or nconfig. When using xconfig, and selecting "Virtual terminal" VT, xconfig help does say: type: bool unknown property: symbol dep: TTY && !UML prompt: Virtual terminal dep: TTY && !UML && EXPERT <<<<< so the prompt depends on EXPERT select: INPUT dep: TTY && !UML default: y dep: TTY && !UML -- ~Randy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 1:45 ` Rob Landley 2019-12-31 2:00 ` Randy Dunlap @ 2019-12-31 2:04 ` Rob Landley 2019-12-31 2:03 ` Randy Dunlap 2019-12-31 2:40 ` Al Viro 1 sibling, 2 replies; 25+ messages in thread From: Rob Landley @ 2019-12-31 2:04 UTC (permalink / raw) To: Randy Dunlap, linux-kernel On 12/30/19 7:45 PM, Rob Landley wrote: > On 12/30/19 6:59 PM, Randy Dunlap wrote: >> # >> # Character devices >> # >> CONFIG_TTY=y >> # CONFIG_VT is not set >> >> But first you must set/enable EXPERT. See the bool prompt. > > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the > symbol, but the symbol can still be on (and displayed) when the if is false? > (Why would...) > > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no > mention of this? So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on: ./init/Kconfig: bool "Namespaces support" if EXPERT ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT ./init/Kconfig: bool "Sysfs syscall support" if EXPERT ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT ./init/Kconfig: bool "Enable support for printk" if EXPERT ./init/Kconfig: bool "BUG() support" if EXPERT ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT ./init/Kconfig: bool "Enable futex support" if EXPERT ./init/Kconfig: bool "Enable eventpoll support" if EXPERT ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT ./init/Kconfig: bool "Enable AIO support" if EXPERT ./init/Kconfig: bool "Enable IO uring support" if EXPERT ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT ./init/Kconfig: bool "Enable rseq() system call" if EXPERT ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT ./init/Kconfig: bool "PC/104 support" if EXPERT ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT plus of course ./arch/x86/Kconfig.cpu: bool "Supported processor vendors" if EXPERT ./arch/x86/Kconfig: bool "DMA memory allocation support" if EXPERT ./arch/x86/Kconfig: bool "Enable DMI scanning" if EXPERT ./arch/x86/Kconfig: bool "Enable support for 16-bit segments" if EXPERT ./arch/x86/Kconfig: bool "Enable vsyscall emulation" if EXPERT ./arch/x86/Kconfig: bool "Enable the LDT (local descriptor table)" if EXPERT ./arch/x86/Kconfig: bool "Read CNB20LE Host Bridge Windows" if EXPERT ./arch/x86/Kconfig: bool "ISA bus support on modern systems" if EXPERT ./arch/x86/Kconfig: bool "ISA-style DMA support" if (X86_64 && EXPERT) So nobody noticed you have a structural "this config option actually switches this thing _off_" implemented via magic symbol then? I think the right fix here involves running sed after kconfig does its thing... Rob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 2:04 ` Rob Landley @ 2019-12-31 2:03 ` Randy Dunlap 2019-12-31 2:33 ` Theodore Y. Ts'o 2019-12-31 2:40 ` Al Viro 1 sibling, 1 reply; 25+ messages in thread From: Randy Dunlap @ 2019-12-31 2:03 UTC (permalink / raw) To: Rob Landley, linux-kernel On 12/30/19 6:04 PM, Rob Landley wrote: > > > On 12/30/19 7:45 PM, Rob Landley wrote: >> On 12/30/19 6:59 PM, Randy Dunlap wrote: >>> # >>> # Character devices >>> # >>> CONFIG_TTY=y >>> # CONFIG_VT is not set >>> >>> But first you must set/enable EXPERT. See the bool prompt. >> >> Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the >> symbol, but the symbol can still be on (and displayed) when the if is false? >> (Why would...) >> >> Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no >> mention of this? > > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on: > > ./init/Kconfig: bool "Namespaces support" if EXPERT > ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT > ./init/Kconfig: bool "Sysfs syscall support" if EXPERT > ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT > ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT > ./init/Kconfig: bool "Enable support for printk" if EXPERT > ./init/Kconfig: bool "BUG() support" if EXPERT > ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT > ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT > ./init/Kconfig: bool "Enable futex support" if EXPERT > ./init/Kconfig: bool "Enable eventpoll support" if EXPERT > ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT > ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT > ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT > ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT > ./init/Kconfig: bool "Enable AIO support" if EXPERT > ./init/Kconfig: bool "Enable IO uring support" if EXPERT > ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT > ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT > ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT > ./init/Kconfig: bool "Enable rseq() system call" if EXPERT > ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT > ./init/Kconfig: bool "PC/104 support" if EXPERT > ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT > > plus of course > > ./arch/x86/Kconfig.cpu: bool "Supported processor vendors" if EXPERT > ./arch/x86/Kconfig: bool "DMA memory allocation support" if EXPERT > ./arch/x86/Kconfig: bool "Enable DMI scanning" if EXPERT > ./arch/x86/Kconfig: bool "Enable support for 16-bit segments" if EXPERT > ./arch/x86/Kconfig: bool "Enable vsyscall emulation" if EXPERT > ./arch/x86/Kconfig: bool "Enable the LDT (local descriptor table)" if EXPERT > ./arch/x86/Kconfig: bool "Read CNB20LE Host Bridge Windows" if EXPERT > ./arch/x86/Kconfig: bool "ISA bus support on modern systems" if EXPERT > ./arch/x86/Kconfig: bool "ISA-style DMA support" if (X86_64 && EXPERT) > > So nobody noticed you have a structural "this config option actually switches > this thing _off_" implemented via magic symbol then? I guess nobody had a problem with it for the last 10 or 15 or 20 years. > I think the right fix here involves running sed after kconfig does its thing... I doubt that would work, but if it does, go for it. -- ~Randy ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 2:03 ` Randy Dunlap @ 2019-12-31 2:33 ` Theodore Y. Ts'o 0 siblings, 0 replies; 25+ messages in thread From: Theodore Y. Ts'o @ 2019-12-31 2:33 UTC (permalink / raw) To: Randy Dunlap; +Cc: Rob Landley, linux-kernel On Mon, Dec 30, 2019 at 06:03:26PM -0800, Randy Dunlap wrote: > > > > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on: > > > > ./init/Kconfig: bool "Namespaces support" if EXPERT > > > > So nobody noticed you have a structural "this config option actually switches > > this thing _off_" implemented via magic symbol then? Perhaps because the right thing happens if you enable CONFIG_EXPERT using "make menuconfig"? It also looks like the right thing happens if you edit the .config and then run "make oldconfig". Personally, I never use miniconfig, so it's not anything *I* ever noticed in all of my years of kernel development. Usually, the way that I manage configs is "make menuconfig", or editing the .config directly, or "make savedefconfig" / "make olddefconfig". Cheers, - Ted ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 2:04 ` Rob Landley 2019-12-31 2:03 ` Randy Dunlap @ 2019-12-31 2:40 ` Al Viro 2019-12-31 2:52 ` Al Viro 1 sibling, 1 reply; 25+ messages in thread From: Al Viro @ 2019-12-31 2:40 UTC (permalink / raw) To: Rob Landley; +Cc: Randy Dunlap, linux-kernel On Mon, Dec 30, 2019 at 08:04:35PM -0600, Rob Landley wrote: > > > On 12/30/19 7:45 PM, Rob Landley wrote: > > On 12/30/19 6:59 PM, Randy Dunlap wrote: > >> # > >> # Character devices > >> # > >> CONFIG_TTY=y > >> # CONFIG_VT is not set > >> > >> But first you must set/enable EXPERT. See the bool prompt. > > > > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the > > symbol, but the symbol can still be on (and displayed) when the if is false? > > (Why would...) > > > > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no > > mention of this? > > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on: > > ./init/Kconfig: bool "Namespaces support" if EXPERT > ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT > ./init/Kconfig: bool "Sysfs syscall support" if EXPERT > ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT > ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT > ./init/Kconfig: bool "Enable support for printk" if EXPERT > ./init/Kconfig: bool "BUG() support" if EXPERT > ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT > ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT > ./init/Kconfig: bool "Enable futex support" if EXPERT > ./init/Kconfig: bool "Enable eventpoll support" if EXPERT > ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT > ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT > ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT > ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT > ./init/Kconfig: bool "Enable AIO support" if EXPERT > ./init/Kconfig: bool "Enable IO uring support" if EXPERT > ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT > ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT > ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT > ./init/Kconfig: bool "Enable rseq() system call" if EXPERT > ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT > ./init/Kconfig: bool "PC/104 support" if EXPERT > ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT No. What you need is * actually attempt to flip CONFIG_EXPERT (go to "General setup" submenu and set "Configure standard kernel features (expert users)" there) * check the resulting .config (or look at the items in question via menuconfig) * get enlightened Rob, if you are in a mood for a long wank, it's your business. But try to avoid spraying the results over public lists. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 2:40 ` Al Viro @ 2019-12-31 2:52 ` Al Viro 2019-12-31 3:27 ` Rob Landley 0 siblings, 1 reply; 25+ messages in thread From: Al Viro @ 2019-12-31 2:52 UTC (permalink / raw) To: Rob Landley; +Cc: Randy Dunlap, linux-kernel On Tue, Dec 31, 2019 at 02:40:54AM +0000, Al Viro wrote: > On Mon, Dec 30, 2019 at 08:04:35PM -0600, Rob Landley wrote: > > > > > > On 12/30/19 7:45 PM, Rob Landley wrote: > > > On 12/30/19 6:59 PM, Randy Dunlap wrote: > > >> # > > >> # Character devices > > >> # > > >> CONFIG_TTY=y > > >> # CONFIG_VT is not set > > >> > > >> But first you must set/enable EXPERT. See the bool prompt. > > > > > > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the > > > symbol, but the symbol can still be on (and displayed) when the if is false? > > > (Why would...) > > > > > > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no > > > mention of this? > > > > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on: > > > > ./init/Kconfig: bool "Namespaces support" if EXPERT > > ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT > > ./init/Kconfig: bool "Sysfs syscall support" if EXPERT > > ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT > > ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT > > ./init/Kconfig: bool "Enable support for printk" if EXPERT > > ./init/Kconfig: bool "BUG() support" if EXPERT > > ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT > > ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT > > ./init/Kconfig: bool "Enable futex support" if EXPERT > > ./init/Kconfig: bool "Enable eventpoll support" if EXPERT > > ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT > > ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT > > ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT > > ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT > > ./init/Kconfig: bool "Enable AIO support" if EXPERT > > ./init/Kconfig: bool "Enable IO uring support" if EXPERT > > ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT > > ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT > > ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT > > ./init/Kconfig: bool "Enable rseq() system call" if EXPERT > > ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT > > ./init/Kconfig: bool "PC/104 support" if EXPERT > > ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT > > No. What you need is > * actually attempt to flip CONFIG_EXPERT (go to "General setup" submenu and > set "Configure standard kernel features (expert users)" there) > * check the resulting .config (or look at the items in question via > menuconfig) > * get enlightened > > Rob, if you are in a mood for a long wank, it's your business. But try to avoid > spraying the results over public lists. To elaborate: you are complaining about VT being treated the same way as e.g. ELF_CORE or UID16. Which might or might not be reasonable, but kconfig folks have nothing to do with that. Your complaint is basically that the same thing is forcing all of those on in default configs. Instead of having a separate ROB_WANTS_THOSE that would prop the rest, but not VT (and frankly, quite a bit of that rest is questionable for minimal setups). With ROB_WANTS_THOSE (or equivalent information) enshrined in the kernel tree for your convenience. Pardon me, but... why is that anyone else's problem? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 2:52 ` Al Viro @ 2019-12-31 3:27 ` Rob Landley 2019-12-31 3:53 ` Al Viro 0 siblings, 1 reply; 25+ messages in thread From: Rob Landley @ 2019-12-31 3:27 UTC (permalink / raw) To: Al Viro; +Cc: Randy Dunlap, linux-kernel On 12/30/19 8:52 PM, Al Viro wrote: >> Rob, if you are in a mood for a long wank, it's your business. But try to avoid >> spraying the results over public lists. I don't post regularly here anymore, but it's good to see the code of conduct and Linus's sabbatical have had a positive effect on the place in my absence. > To elaborate: you are complaining about VT being treated the same way as e.g. > ELF_CORE or UID16. Which might or might not be reasonable, but kconfig folks > have nothing to do with that. > > Your complaint is basically that the same thing is forcing all of those on > in default configs. No, my complaint was that kconfig basically has the concept of symbols that turn _off_ something that is otherwise on by default ("Disable X" instead of "Enable X"), but it was implemented it in an awkward way then allowed to scale to silly levels, and now the fact it exists is being used as evidence that it was a good idea. I had to work out a way to work around this design breakage, which I did and had moved on before this email, but I thought pointing out the awkwardness might help a design discussion. My mistake. The thread _started_ because menuconfig help has a blind spot (which seemed like a bug to me, it _used_ to say why), and then I found the syntax you changed a year or two back non-obvious when I tried to RTFM but that part got answered. > Instead of having a separate ROB_WANTS_THOSE that would > prop the rest, but not VT (and frankly, quite a bit of that rest is > questionable for minimal setups). With ROB_WANTS_THOSE (or equivalent > information) enshrined in the kernel tree for your convenience. > > Pardon me, but... why is that anyone else's problem? You drove everybody away who would express similar concerns years ago. None of my co-workers have wanted to get linux-kernel on them in ages. (I thought that sort of thing was why you were having a code of conduct and such, but apparently not.) *shrug* I'll try to be more proactive about stripping linux-kernel from the cc: list once I've got a human's attention in a thread. (Or just try to dig up somebody to email directly via git history and the maintainers file.) I leave you to your sexual metaphors, Rob ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 3:27 ` Rob Landley @ 2019-12-31 3:53 ` Al Viro 2019-12-31 4:18 ` Al Viro 0 siblings, 1 reply; 25+ messages in thread From: Al Viro @ 2019-12-31 3:53 UTC (permalink / raw) To: Rob Landley; +Cc: Randy Dunlap, linux-kernel On Mon, Dec 30, 2019 at 09:27:50PM -0600, Rob Landley wrote: > > Your complaint is basically that the same thing is forcing all of those on > > in default configs. > > No, my complaint was that kconfig basically has the concept of symbols that turn > _off_ something that is otherwise on by default ("Disable X" instead of "Enable > X"), but it was implemented it in an awkward way then allowed to scale to silly > levels, and now the fact it exists is being used as evidence that it was a good > idea. Where and by whom? > I had to work out a way to work around this design breakage, which I did and had > moved on before this email, but I thought pointing out the awkwardness might > help a design discussion. What design discussion? Where? > My mistake. Generally a passive-aggressive flame (complete with comparisons to INTERCAL) and not a shred of reference to any design issues in it tends to be rather ineffecient way to start such discussion... > The thread _started_ because menuconfig help has a blind spot (which seemed like > a bug to me, it _used_ to say why), and then I found the syntax you changed a > year or two back non-obvious when I tried to RTFM but that part got answered. _I_ have changed??? What the hell? I have never touched kconfig syntax in any way; what are you talking about? Care to post commit IDs in question? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 3:53 ` Al Viro @ 2019-12-31 4:18 ` Al Viro 2019-12-31 5:58 ` Al Viro 0 siblings, 1 reply; 25+ messages in thread From: Al Viro @ 2019-12-31 4:18 UTC (permalink / raw) To: Rob Landley; +Cc: Randy Dunlap, linux-kernel On Tue, Dec 31, 2019 at 03:53:19AM +0000, Al Viro wrote: > On Mon, Dec 30, 2019 at 09:27:50PM -0600, Rob Landley wrote: > > > > Your complaint is basically that the same thing is forcing all of those on > > > in default configs. > > > > No, my complaint was that kconfig basically has the concept of symbols that turn > > _off_ something that is otherwise on by default ("Disable X" instead of "Enable > > X"), but it was implemented it in an awkward way then allowed to scale to silly > > levels, and now the fact it exists is being used as evidence that it was a good > > idea. > > Where and by whom? > > > I had to work out a way to work around this design breakage, which I did and had > > moved on before this email, but I thought pointing out the awkwardness might > > help a design discussion. > > What design discussion? Where? > > > My mistake. > > Generally a passive-aggressive flame (complete with comparisons to INTERCAL) > and not a shred of reference to any design issues in it tends to > be rather ineffecient way to start such discussion... > > > The thread _started_ because menuconfig help has a blind spot (which seemed like > > a bug to me, it _used_ to say why), and then I found the syntax you changed a > > year or two back non-obvious when I tried to RTFM but that part got answered. > > _I_ have changed??? What the hell? I have never touched kconfig syntax in any > way; what are you talking about? Care to post commit IDs in question? BTW, in 2.6.12 drivers/char/Kconfig has config VT bool "Virtual terminal" if EMBEDDED so the syntax appears to be identical all way back to 2005. Going to the historical tree, we have commit eda30c2b338cdc099951f45eb45d1ce7055706e3 Author: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Thu Jul 31 05:15:05 2003 -0700 [PATCH] console on by default if not embedded (save mucho pain) (Andi Kleen) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index f0ce5d7473ad..d16c54b65102 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -5,8 +5,9 @@ menu "Character devices" config VT - bool "Virtual terminal" + bool "Virtual terminal" if EMBEDDED requires INPUT=y + default y So application of that particular syntax to VT goes back to 2003. I've no idea how far back the syntax itself goes. One change that might be relevant appears to have happened circa 3.15, when allnoconfig started playing odd games with EXPERT; bisect points to commit 5d2acfc7b974bbd3858b4dd3f2cdc6362dd8843a Author: Josh Triplett <josh@joshtriplett.org> Date: Mon Apr 7 15:39:09 2014 -0700 kconfig: make allnoconfig disable options behind EMBEDDED and EXPERT Mind explaining what exactly are you talking about and how exactly have I been involved in it? My only involvement with kconfig (thorough all its history) had been commit 6b87b70c5339f30e3c5b32085e69625906513dc2 Author: Al Viro <viro@ZenIV.linux.org.uk> Date: Thu Jan 14 18:13:49 2016 +0000 unbreak allmodconfig KCONFIG_ALLCONFIG=... and commit ce97e13e52848c6388598696b7d44748598db759 Author: Al Viro <viro@ZenIV.linux.org.uk> Date: Sun Oct 26 05:12:34 2008 +0000 fix allmodconfig breakage Neither of those has happened within the last couple of years and if either has caused any breakage relevant to whatever you are doing, I would rather hear details. Certainly no syntax changes had been intended by either commit and rereading those I see no likely candidates. ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 4:18 ` Al Viro @ 2019-12-31 5:58 ` Al Viro 2020-01-01 20:41 ` [PATCH] menuconfig: restore prompt dependencies in help text Arvind Sankar 0 siblings, 1 reply; 25+ messages in thread From: Al Viro @ 2019-12-31 5:58 UTC (permalink / raw) To: Rob Landley; +Cc: Randy Dunlap, linux-kernel On Tue, Dec 31, 2019 at 04:18:15AM +0000, Al Viro wrote: > > > The thread _started_ because menuconfig help has a blind spot (which seemed like > > > a bug to me, it _used_ to say why), and then I found the syntax you changed a > > > year or two back non-obvious when I tried to RTFM but that part got answered. FWIW, the change of help message (from reporting Depends on: TTY [=y] && !S390 && !UML && EXPERT [=n] to Depends on: TTY [=y] && !S390 && !UML) seems to have come about in commit bcdedcc1afd6ac91e15cb90aedaf8432f62fed13 Author: Wengmeiling <wengmeiling.weng@huawei.com> Date: Tue Apr 30 15:28:46 2013 -0700 menuconfig: print more info for symbol without prompts Doesn't seem to be intentional, going by the commit message, and I'm not familiar enough with menuconfig guts to tell more than that without serious RTFS. So if you are refering to the help message contents (its syntax doesn't seem to have changed), that would appear to be the point when it has happened (3.10, six and half years ago). If you are refering to the syntax of Kconfig itself, AFAICS that has remained since the introduction of Kconfig back in 2002 - at least the earliest version of the parser seems to have it that way. Hadn't checked how soon the first users have appeared, but no later than in 2003. No idea about the earlier history - it went into the tree in that form. No opinion about the merits of Kconfig syntax, BTW. The older form of reported dependencies looks strange, now that I look at it (never noticed that quirk back then) - usually <something> && <option> [=n] would've meant that the entire expression is false; if anything, it might've been better to report the predicates on prompt separately. No idea how hard would that be - I hadn't looked into menuconfig guts for years, and even then only casually. FWIW, my only contact with KCONFIG_ALLCONFIG mechanism had been on the build coverage side of things - i.e. allmodconfig with fixed subset. Never played with allnoconfig applications, but AFAICS the only (relatively) recent change I'd done there hadn't changed allnoconfig behaviour at all. ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH] menuconfig: restore prompt dependencies in help text 2019-12-31 5:58 ` Al Viro @ 2020-01-01 20:41 ` Arvind Sankar 2020-01-01 21:04 ` Al Viro 0 siblings, 1 reply; 25+ messages in thread From: Arvind Sankar @ 2020-01-01 20:41 UTC (permalink / raw) To: Masahiro Yamada, linux-kbuild Cc: Al Viro, Rob Landley, Randy Dunlap, linux-kernel Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts") moved some code from get_prompt_str to get_symbol_str so that dependency information for symbols without prompts could be shown. This code would be better copied rather than moved, as the change had the side-effect of not showing any extra dependencies that the prompt might have over the symbol. Put back a copy of the dependency printing code in get_prompt_str. The following is an example for NAMESPACES: Before: Symbol: NAMESPACES [=y] Type : bool Prompt: Namespaces support Location: (2) -> General setup Defined at init/Kconfig:1064 Depends on: MULTIUSER [=y] After: Symbol: NAMESPACES [=y] Type : bool Prompt: Namespaces support Visible if: MULTIUSER [=y] && EXPERT [=y] Location: (2) -> General setup Defined at init/Kconfig:1064 Depends on: MULTIUSER [=y] Fixes: bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts") Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> --- scripts/kconfig/menu.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c index d9d16469859a..c323ab4ac7c7 100644 --- a/scripts/kconfig/menu.c +++ b/scripts/kconfig/menu.c @@ -706,6 +706,12 @@ static void get_prompt_str(struct gstr *r, struct property *prop, struct jump_key *jump = NULL; str_printf(r, "Prompt: %s\n", prop->text); + if (!expr_is_yes(prop->visible.expr)) { + str_append(r, " Visible if: "); + expr_gstr_print(prop->visible.expr, r); + str_append(r, "\n"); + } + menu = prop->menu->parent; for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent) { bool accessible = menu_is_visible(menu); -- 2.24.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] menuconfig: restore prompt dependencies in help text 2020-01-01 20:41 ` [PATCH] menuconfig: restore prompt dependencies in help text Arvind Sankar @ 2020-01-01 21:04 ` Al Viro 2020-01-01 22:26 ` Arvind Sankar 0 siblings, 1 reply; 25+ messages in thread From: Al Viro @ 2020-01-01 21:04 UTC (permalink / raw) To: Arvind Sankar Cc: Masahiro Yamada, linux-kbuild, Rob Landley, Randy Dunlap, linux-kernel On Wed, Jan 01, 2020 at 03:41:52PM -0500, Arvind Sankar wrote: > Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without > prompts") moved some code from get_prompt_str to get_symbol_str so that > dependency information for symbols without prompts could be shown. > > This code would be better copied rather than moved, as the change had > the side-effect of not showing any extra dependencies that the prompt > might have over the symbol. > > Put back a copy of the dependency printing code in get_prompt_str. Umm... Is "visible" really accurate in this case? AFAICS, the entry (and help for it) _is_ visible with EXPERT=n. OTOH, with EXPERT=y and MULTIUSER=n it disappears completely. I'm not familiar with kconfig guts (and not too concerned about that feature of help there, TBH), but it looks like what you are printing there is some mix of dependencies ("visible when") and selectability... ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] menuconfig: restore prompt dependencies in help text 2020-01-01 21:04 ` Al Viro @ 2020-01-01 22:26 ` Arvind Sankar 2020-01-02 16:14 ` Randy Dunlap 0 siblings, 1 reply; 25+ messages in thread From: Arvind Sankar @ 2020-01-01 22:26 UTC (permalink / raw) To: Al Viro Cc: Arvind Sankar, Masahiro Yamada, linux-kbuild, Rob Landley, Randy Dunlap, linux-kernel On Wed, Jan 01, 2020 at 09:04:26PM +0000, Al Viro wrote: > On Wed, Jan 01, 2020 at 03:41:52PM -0500, Arvind Sankar wrote: > > Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without > > prompts") moved some code from get_prompt_str to get_symbol_str so that > > dependency information for symbols without prompts could be shown. > > > > This code would be better copied rather than moved, as the change had > > the side-effect of not showing any extra dependencies that the prompt > > might have over the symbol. > > > > Put back a copy of the dependency printing code in get_prompt_str. > > Umm... Is "visible" really accurate in this case? AFAICS, the > entry (and help for it) _is_ visible with EXPERT=n. OTOH, with > EXPERT=y and MULTIUSER=n it disappears completely. > > I'm not familiar with kconfig guts (and not too concerned about that > feature of help there, TBH), but it looks like what you are printing > there is some mix of dependencies ("visible when") and selectability... Perhaps not the most accurate term. For NAMESPACES it has a submenu, so it can't disappear as long as its selected, even if it's not editable any more. A "leaf" level option like MULTIUSER, otoh, does disappear completely (even though it's still selected). But there are also things like CONFIG_VT, which stays visible, even though its not a menu.. I think because there is a visible option that depends on it and immediately follows, which menuconfig shows by indenting. If the order of UNIX98_PTYS and VT_HW_CONSOLE_BINDING is flipped in drivers/tty/Kconfig, then VT disappears when EXPERT=n. Dunno, maybe Editable would be a better word than Visible? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] menuconfig: restore prompt dependencies in help text 2020-01-01 22:26 ` Arvind Sankar @ 2020-01-02 16:14 ` Randy Dunlap 2020-01-02 23:14 ` [PATCH] kconfig: " Arvind Sankar 0 siblings, 1 reply; 25+ messages in thread From: Randy Dunlap @ 2020-01-02 16:14 UTC (permalink / raw) To: Arvind Sankar, Al Viro Cc: Masahiro Yamada, linux-kbuild, Rob Landley, linux-kernel On 1/1/20 2:26 PM, Arvind Sankar wrote: > On Wed, Jan 01, 2020 at 09:04:26PM +0000, Al Viro wrote: >> On Wed, Jan 01, 2020 at 03:41:52PM -0500, Arvind Sankar wrote: >>> Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without >>> prompts") moved some code from get_prompt_str to get_symbol_str so that >>> dependency information for symbols without prompts could be shown. >>> >>> This code would be better copied rather than moved, as the change had >>> the side-effect of not showing any extra dependencies that the prompt >>> might have over the symbol. >>> >>> Put back a copy of the dependency printing code in get_prompt_str. >> >> Umm... Is "visible" really accurate in this case? AFAICS, the >> entry (and help for it) _is_ visible with EXPERT=n. OTOH, with >> EXPERT=y and MULTIUSER=n it disappears completely. >> >> I'm not familiar with kconfig guts (and not too concerned about that >> feature of help there, TBH), but it looks like what you are printing >> there is some mix of dependencies ("visible when") and selectability... > > Perhaps not the most accurate term. For NAMESPACES it has a submenu, so > it can't disappear as long as its selected, even if it's not editable > any more. A "leaf" level option like MULTIUSER, otoh, does disappear > completely (even though it's still selected). > > But there are also things like CONFIG_VT, which stays visible, even > though its not a menu.. I think because there is a visible option that > depends on it and immediately follows, which menuconfig shows by > indenting. If the order of UNIX98_PTYS and VT_HW_CONSOLE_BINDING is > flipped in drivers/tty/Kconfig, then VT disappears when EXPERT=n. > > Dunno, maybe Editable would be a better word than Visible? I would prefer Editable instead of Visible. and the Subject should be more than menuconfig since the patch also "fixes" nconfig, xconfig, and gconfig. Tested-by: Randy Dunlap <rdunlap@infradead.org> Thanks. -- ~Randy ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH] kconfig: restore prompt dependencies in help text 2020-01-02 16:14 ` Randy Dunlap @ 2020-01-02 23:14 ` Arvind Sankar 2020-01-03 2:10 ` Masahiro Yamada 0 siblings, 1 reply; 25+ messages in thread From: Arvind Sankar @ 2020-01-02 23:14 UTC (permalink / raw) To: Masahiro Yamada, linux-kbuild Cc: Al Viro, Rob Landley, Randy Dunlap, linux-kernel Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts") moved some code from get_prompt_str to get_symbol_str so that dependency information for symbols without prompts could be shown. This code would be better copied rather than moved, as the change had the side-effect of not showing any extra dependencies that the prompt might have over the symbol. Put back a copy of the dependency printing code in get_prompt_str. The following is an example for NAMESPACES: Before: Symbol: NAMESPACES [=y] Type : bool Prompt: Namespaces support Location: (2) -> General setup Defined at init/Kconfig:1064 Depends on: MULTIUSER [=y] After: Symbol: NAMESPACES [=y] Type : bool Prompt: Namespaces support Editable if: MULTIUSER [=y] && EXPERT [=y] Location: (2) -> General setup Defined at init/Kconfig:1064 Depends on: MULTIUSER [=y] Fixes: bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts") Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> --- scripts/kconfig/menu.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c index d9d16469859a..6fbbe41302dc 100644 --- a/scripts/kconfig/menu.c +++ b/scripts/kconfig/menu.c @@ -706,6 +706,12 @@ static void get_prompt_str(struct gstr *r, struct property *prop, struct jump_key *jump = NULL; str_printf(r, "Prompt: %s\n", prop->text); + if (!expr_is_yes(prop->visible.expr)) { + str_append(r, " Editable if: "); + expr_gstr_print(prop->visible.expr, r); + str_append(r, "\n"); + } + menu = prop->menu->parent; for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent) { bool accessible = menu_is_visible(menu); -- 2.24.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] kconfig: restore prompt dependencies in help text 2020-01-02 23:14 ` [PATCH] kconfig: " Arvind Sankar @ 2020-01-03 2:10 ` Masahiro Yamada 2020-01-03 4:20 ` Arvind Sankar 0 siblings, 1 reply; 25+ messages in thread From: Masahiro Yamada @ 2020-01-03 2:10 UTC (permalink / raw) To: Arvind Sankar Cc: Linux Kbuild mailing list, Al Viro, Rob Landley, Randy Dunlap, Linux Kernel Mailing List On Fri, Jan 3, 2020 at 8:14 AM Arvind Sankar <nivedita@alum.mit.edu> wrote: > > Commit bcdedcc1afd6 ("menuconfig: print more info for symbol without > prompts") moved some code from get_prompt_str to get_symbol_str so that > dependency information for symbols without prompts could be shown. > > This code would be better copied rather than moved, as the change had > the side-effect of not showing any extra dependencies that the prompt > might have over the symbol. > > Put back a copy of the dependency printing code in get_prompt_str. > > The following is an example for NAMESPACES: > > Before: > Symbol: NAMESPACES [=y] > Type : bool > Prompt: Namespaces support > Location: > (2) -> General setup > Defined at init/Kconfig:1064 > Depends on: MULTIUSER [=y] > > After: > Symbol: NAMESPACES [=y] > Type : bool > Prompt: Namespaces support > Editable if: MULTIUSER [=y] && EXPERT [=y] > Location: > (2) -> General setup > Defined at init/Kconfig:1064 > Depends on: MULTIUSER [=y] > > Fixes: bcdedcc1afd6 ("menuconfig: print more info for symbol without prompts") > Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> > --- I had already applied the following patch; https://patchwork.kernel.org/patch/11298143/ It it available in linux-next. > scripts/kconfig/menu.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c > index d9d16469859a..6fbbe41302dc 100644 > --- a/scripts/kconfig/menu.c > +++ b/scripts/kconfig/menu.c > @@ -706,6 +706,12 @@ static void get_prompt_str(struct gstr *r, struct property *prop, > struct jump_key *jump = NULL; > > str_printf(r, "Prompt: %s\n", prop->text); > + if (!expr_is_yes(prop->visible.expr)) { > + str_append(r, " Editable if: "); > + expr_gstr_print(prop->visible.expr, r); > + str_append(r, "\n"); > + } > + > menu = prop->menu->parent; > for (i = 0; menu != &rootmenu && i < 8; menu = menu->parent) { > bool accessible = menu_is_visible(menu); > -- > 2.24.1 > -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] kconfig: restore prompt dependencies in help text 2020-01-03 2:10 ` Masahiro Yamada @ 2020-01-03 4:20 ` Arvind Sankar 0 siblings, 0 replies; 25+ messages in thread From: Arvind Sankar @ 2020-01-03 4:20 UTC (permalink / raw) To: Masahiro Yamada Cc: Arvind Sankar, Linux Kbuild mailing list, Al Viro, Rob Landley, Randy Dunlap, Linux Kernel Mailing List On Fri, Jan 03, 2020 at 11:10:28AM +0900, Masahiro Yamada wrote: > > I had already applied the following patch; > https://patchwork.kernel.org/patch/11298143/ > > It it available in linux-next. > Oh cool ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 0:30 Why is CONFIG_VT forced on? Rob Landley 2019-12-31 0:36 ` Randy Dunlap @ 2019-12-31 1:55 ` Theodore Y. Ts'o 2020-01-04 20:27 ` Enrico Weigelt, metux IT consult 2019-12-31 2:28 ` Al Viro 2 siblings, 1 reply; 25+ messages in thread From: Theodore Y. Ts'o @ 2019-12-31 1:55 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel On Mon, Dec 30, 2019 at 06:30:15PM -0600, Rob Landley wrote: > On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual > terminal), but the help doesn't mention a "selects", and I didn't spot anything > obvious in "find . -name 'Kconfig*' | xargs grep -rw VT". It's forced on because of this: config VT bool "Virtual terminal" if EXPERT ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The above is syntatic sugar for this: bool prompt "Virtual terminal" if EXPERT What this means is that the prompt is shown only if CONFIG_EXPERT is enabled. If CONFIG_EXPERT is not set, then the default value (which for CONFIG_VT is "yes") is used, with no way to change it. Basically, this is because we don't want naive users to build a kernel which displays nothing on the console; for PC class systems, 99.99% of the time, you really do want the virtual terminal enabled. > Congratulations, you've reinvented "come from". I'm mostly familiar with the > kconfig plumbing from _before_ you made it turing complete: how do I navigate this? In the case where something was actually selected, it is explained as such when you search for that config variable. So for example, if you run "make menuconfig", and then type '/' to search for a configuration parameter, and then type "CONFIG_JBD2" and return. What you will see is this: Symbol: JBD2 [=y] │ Type : tristate │ Defined at fs/jbd2/Kconfig:2 │ Depends on: BLOCK [=y] │ Selects: CRC32 [=y] && CRYPTO [=y] && CRYPTO_CRC32C [=y] │ Selected by [y]: │ - EXT4_FS [=y] && BLOCK [=y] │ Selected by [n]: │ - EXT3_FS [=n] && BLOCK [=y] │ - OCFS2_FS [=n] && BLOCK [=y] && NET [=y] && SYSFS [=y] && CONFIGFS_FS [=y] The values in square brackets tell you what the current value of these configuration parameters. So it tells you that CONFIG_JBD2 is yes, CONFIG_BLOCK is yes, EXT3_FS is no, OCFS2_FS is no, etc. It also tells you that it is currently selected automatically because CONFIG_EXT4_FS and CONFIG_BLOCK is enabled. If CONFIG_EXT3_FS and CONFIG_BLOCK was yes, that would also cause CONFIG_JBD2 to be selected. And since CONFIG_JBD2 is enabled, it will force CONFIG_CRC32, CONFIG_CRYPTO, and CONFIG_CRC32C to be selected. It also tells you that you can find the actual definition at fs/jbd2/Kconfig, at line #2. > I'm guessing "stick printfs into the menuconfig binary" is the recommended next > step for investigating this? Or is there a trick I'm missing? See above. The menuconfig configuration parameter search feature tells you all about how a particular CONFIG_XXX, and what dependencies to be enabled in order for you to be able enable that parameter, and why it might have been enabled via the select command. What's not there is an explanation for why a parameter like CONFIG_VT is enabled. Right now, /CONFIG_VT will display: Symbol: VT [=y] Type : bool Prompt: Virtual terminal Location: -> Device Drivers -> Character devices (1) -> Enable TTY (TTY [=y]) Defined at drivers/tty/Kconfig:13 Depends on: TTY [=y] && !UML Selects: INPUT [=y] Now, if you look at line 13 of drivers/tty/Kconfig, you'd see: config VT bool "Virtual terminal" if EXPERT depends on !UML select INPUT default y ---help--- If you say Y here, you will get support for terminal devices with ... Perhaps it would be nice if the output of /CONFIG_VT included something like: Prompt requires CONFIG_EXPERT [=n], default y I'm sure the kbuild maintainers would love to consider a patch which did this. :-) Cheers, - Ted ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 1:55 ` Why is CONFIG_VT forced on? Theodore Y. Ts'o @ 2020-01-04 20:27 ` Enrico Weigelt, metux IT consult 0 siblings, 0 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2020-01-04 20:27 UTC (permalink / raw) To: Theodore Y. Ts'o, Rob Landley; +Cc: linux-kernel On 31.12.19 02:55, Theodore Y. Ts'o wrote: Hi, > What this means is that the prompt is shown only if CONFIG_EXPERT is > enabled. If CONFIG_EXPERT is not set, then the default value (which > for CONFIG_VT is "yes") is used, with no way to change it. So, if one manually changes that in .config and re-runs 'make menuconfig' again, it will be forced back to the default ? > What's not there is an explanation for why a parameter like CONFIG_VT > is enabled. That actually would be a good thing to have. I already had lots of cases where I had to spend quite some time in order to find out what caused something to be enabled/disabled/disappearing. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Why is CONFIG_VT forced on? 2019-12-31 0:30 Why is CONFIG_VT forced on? Rob Landley 2019-12-31 0:36 ` Randy Dunlap 2019-12-31 1:55 ` Why is CONFIG_VT forced on? Theodore Y. Ts'o @ 2019-12-31 2:28 ` Al Viro 2 siblings, 0 replies; 25+ messages in thread From: Al Viro @ 2019-12-31 2:28 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel On Mon, Dec 30, 2019 at 06:30:15PM -0600, Rob Landley wrote: > On x86-64 menuconfig, CONFIG_VT is forced on (in drivers->char devices->virtual > terminal), but the help doesn't mention a "selects", and I didn't spot anything > obvious in "find . -name 'Kconfig*' | xargs grep -rw VT". > > Congratulations, you've reinvented "come from". I'm mostly familiar with the > kconfig plumbing from _before_ you made it turing complete: how do I navigate this? > > I'm guessing "stick printfs into the menuconfig binary" is the recommended next > step for investigating this? Or is there a trick I'm missing? config VT bool "Virtual terminal" if EXPERT IOW, it's only conrollable if EXPERT is set. Finding CONFIG_EXPERT, setting it and turning CONFIG_VT off is left as an exercise for reader; ceasing the indignant whining for long enough to do that might or might not be doable - up to you. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2020-01-04 20:28 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-31 0:30 Why is CONFIG_VT forced on? Rob Landley 2019-12-31 0:36 ` Randy Dunlap 2019-12-31 0:53 ` Rob Landley 2019-12-31 0:59 ` Randy Dunlap 2019-12-31 1:45 ` Rob Landley 2019-12-31 2:00 ` Randy Dunlap 2019-12-31 2:04 ` Rob Landley 2019-12-31 2:03 ` Randy Dunlap 2019-12-31 2:33 ` Theodore Y. Ts'o 2019-12-31 2:40 ` Al Viro 2019-12-31 2:52 ` Al Viro 2019-12-31 3:27 ` Rob Landley 2019-12-31 3:53 ` Al Viro 2019-12-31 4:18 ` Al Viro 2019-12-31 5:58 ` Al Viro 2020-01-01 20:41 ` [PATCH] menuconfig: restore prompt dependencies in help text Arvind Sankar 2020-01-01 21:04 ` Al Viro 2020-01-01 22:26 ` Arvind Sankar 2020-01-02 16:14 ` Randy Dunlap 2020-01-02 23:14 ` [PATCH] kconfig: " Arvind Sankar 2020-01-03 2:10 ` Masahiro Yamada 2020-01-03 4:20 ` Arvind Sankar 2019-12-31 1:55 ` Why is CONFIG_VT forced on? Theodore Y. Ts'o 2020-01-04 20:27 ` Enrico Weigelt, metux IT consult 2019-12-31 2:28 ` Al Viro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).