Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp14902884ybl; Mon, 30 Dec 2019 20:19:23 -0800 (PST) X-Google-Smtp-Source: APXvYqyRLBRAtBwZhxZ2/F5YhloduMYzsNvdanjsSLxKp3R317EmwX06BJsE+g5Ext4btAsUgZR7 X-Received: by 2002:a05:6830:3050:: with SMTP id p16mr33342081otr.301.1577765963784; Mon, 30 Dec 2019 20:19:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577765963; cv=none; d=google.com; s=arc-20160816; b=Fo7yYqFWIRU9O5has1HcFphkd4i/cMQcCKoIFKPOQ3gqbCTaiFZJHmwyZMiUoBLRRm 2GHaZ5B1nDJVCYojz4acc1mMErDdk6HvnRRxuhKTT4q6P5NhuEJWyrNAp0pYtyeTpGaj AdZ9n2X4JeYj6PZAO/A5j0pgI6kwG9NyrDrSvvlIFedU8sTjd7Dq5w8imsz8ezSuGiGW hlc3KH9fXwemthWhI1dnii2t6/fCUArLKBwGnhdRkpkcQjXrlFXi0e+N6TQzJc1XENUt ukXNczgRSkh3t2nraw691vua86iz4jfnbm8iZqVmYAArdUklmkfV0fnClIjDgpL6wtUt 7ywA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+CWFh4krLchyNhFXAJ+aT+GafDZSkPqvtjwMpWAh778=; b=oZWMvByZMpR4DsuIYRglMdAletssm3q8Oy4NK5+J7QkQZ/GrTwcK+Ed2nvDwOyDaXI S6oq5aV0LjnQszqBcguEJMWjVFKfHNzHOjSiR+y2dQC1kjgXcOXb5ka3pm5C8/81mNzM fmt/GbJWuyNZfgxs12LzqkeCdNrTZQIF9nREAPXKLSqLq24E42yzsT6wMmXvPvsthA3i M8F1KJFTuwzTqaCgd5eu993307glLuiDiDf2/cZtgbx6a20g4M+ZpZ1eo10cxwx4Kher flzD31ZGXDtKovX2KyTV3ArzzRIu26XIYjCQfL3dUHPdSK1GW6dqNQHVZ9DU5DAu8Qkt WgkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i124si22058002oif.214.2019.12.30.20.19.09; Mon, 30 Dec 2019 20:19:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726538AbfLaESS (ORCPT + 99 others); Mon, 30 Dec 2019 23:18:18 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:56552 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726364AbfLaESR (ORCPT ); Mon, 30 Dec 2019 23:18:17 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1im8z1-0003cH-N5; Tue, 31 Dec 2019 04:18:15 +0000 Date: Tue, 31 Dec 2019 04:18:15 +0000 From: Al Viro To: Rob Landley Cc: Randy Dunlap , linux-kernel@vger.kernel.org Subject: Re: Why is CONFIG_VT forced on? Message-ID: <20191231041815.GF4203@ZenIV.linux.org.uk> References: <9b79fb95-f20c-f299-f568-0ffb60305f04@landley.net> <018540ef-0327-78dc-ea5c-a43318f1f640@landley.net> <774dfe49-61a0-0144-42b7-c2cbac150687@landley.net> <20191231024054.GC4203@ZenIV.linux.org.uk> <20191231025255.GD4203@ZenIV.linux.org.uk> <20191231035319.GE4203@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191231035319.GE4203@ZenIV.linux.org.uk> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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 Date: Thu Jan 14 18:13:49 2016 +0000 unbreak allmodconfig KCONFIG_ALLCONFIG=... and commit ce97e13e52848c6388598696b7d44748598db759 Author: Al Viro 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.