linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Rob Landley <rob@landley.net>
Cc: Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: Why is CONFIG_VT forced on?
Date: Tue, 31 Dec 2019 05:58:39 +0000	[thread overview]
Message-ID: <20191231055839.GG4203@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20191231041815.GF4203@ZenIV.linux.org.uk>

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.

  reply	other threads:[~2019-12-31  5:58 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 [this message]
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

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=20191231055839.GG4203@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.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).