linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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  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: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  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  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  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
* 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  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
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).