linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Rob Landley <rob@landley.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Why is CONFIG_VT forced on?
Date: Mon, 30 Dec 2019 20:55:15 -0500	[thread overview]
Message-ID: <20191231015515.GB3669@mit.edu> (raw)
In-Reply-To: <9b79fb95-f20c-f299-f568-0ffb60305f04@landley.net>

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

  parent reply	other threads:[~2019-12-31  1:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 ` Theodore Y. Ts'o [this message]
2020-01-04 20:27   ` Why is CONFIG_VT forced on? Enrico Weigelt, metux IT consult
2019-12-31  2:28 ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191231015515.GB3669@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).