linux-kernel - Re: Why is CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Dec 2019 05:58:39 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Rob Landley <rob@...dley.net>
Cc:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org
Subject: Re: Why is CONFIG_VT forced on?

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@...wei.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.