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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 31 Dec 2019 04:18:15 +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 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@...rguk.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@...htriplett.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@...IV.linux.org.uk>
Date:   Thu Jan 14 18:13:49 2016 +0000

    unbreak allmodconfig KCONFIG_ALLCONFIG=...
and
commit ce97e13e52848c6388598696b7d44748598db759
Author: Al Viro <viro@...IV.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ