Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp14848996ybl; Mon, 30 Dec 2019 18:54:02 -0800 (PST) X-Google-Smtp-Source: APXvYqwmCRVoGUi/sggHBjLyp7pbM6VpovibpZ/AQCPmUnJl7iQ70RmCr/FHJXDfCU2AsfYhDqUI X-Received: by 2002:a9d:2264:: with SMTP id o91mr79060670ota.328.1577760842688; Mon, 30 Dec 2019 18:54:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577760842; cv=none; d=google.com; s=arc-20160816; b=LzvIhM/CWqezReNFc2AbMaznNmJ2FcwijoE2lUhKRST7M4xtHrWo//3yWySrZ656jM b9i55CzM26hS1NvpFCHwuEnq27AnQmt+IUktomSbhE63XeYQK4YL62H9C8MyXpE83B4I JYXiBN7FNcIJPZApJ14q437+pKwu/RVTI04KOHAvjC7YdEzC2jBwJ7F+cW96M4Tbj1I3 jdOshyguYQUKjUtKSmW7810l3hDR3nSdY8CPlJHbW43pVC/eFClrE1WVNnZYlua/QqQM FkbSb528LxKkrz3Fi8HS1GJWRoy8+47NeM6LcgWcxfyyKbl4yzAkUiMs8TCiwlUMJHIu pY/A== 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=Yldl8D6tfkQwiDEY0ScTKhP6w3RG9zhgUKfYPo26XqU=; b=Jz4UbGz4XTVSu4PbYAl1CHGGoMrNgqkxdbHju90FaXxCS3NuBz5jeRL1t1BPsGwIKl 25K6ZXp2utekfWjeEwlDM04HJ8KqORolbCznSAEL7LAuRFFpLxa0cgT9cSAqOv/ZyQyl PVvvDYaeK7nhpbHEtmo1djH1c9ft5iQRvA47FwTGfi9//B7rB7+JbvfPcjLAn06BQoQc 5Bt38pHjaYwV2MrwmyPjo7du7bjipj4gn8OE3QKwY7Zax6y/BLip+JY7OBV85z7RXxfE Qdm8IvMi5zq/HK8BqgEx6faD+rqca6iQBHcRV6XI8u5b7DGgsxuLOMeBjtoGz5HhWc78 LPZw== 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 9si10999170oiz.237.2019.12.30.18.53.50; Mon, 30 Dec 2019 18:54:02 -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 S1726596AbfLaCw5 (ORCPT + 99 others); Mon, 30 Dec 2019 21:52:57 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:55740 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725536AbfLaCw5 (ORCPT ); Mon, 30 Dec 2019 21:52:57 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1im7eR-00020d-Pk; Tue, 31 Dec 2019 02:52:55 +0000 Date: Tue, 31 Dec 2019 02:52:55 +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: <20191231025255.GD4203@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191231024054.GC4203@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 02:40:54AM +0000, Al Viro wrote: > On Mon, Dec 30, 2019 at 08:04:35PM -0600, Rob Landley wrote: > > > > > > On 12/30/19 7:45 PM, Rob Landley wrote: > > > On 12/30/19 6:59 PM, Randy Dunlap wrote: > > >> # > > >> # Character devices > > >> # > > >> CONFIG_TTY=y > > >> # CONFIG_VT is not set > > >> > > >> But first you must set/enable EXPERT. See the bool prompt. > > > > > > Wait, the if doesn't _disable_ the symbol? It disables _editability_ of the > > > symbol, but the symbol can still be on (and displayed) when the if is false? > > > (Why would...) > > > > > > Ok. Thanks for pointing that out. Any idea why the menuconfig help text has no > > > mention of this? > > > > So if I disable CONFIG_EXPERT, using miniconfig I then need to manually switch on: > > > > ./init/Kconfig: bool "Namespaces support" if EXPERT > > ./init/Kconfig: bool "Multiple users, groups and capabilities support" if EXPERT > > ./init/Kconfig: bool "Sysfs syscall support" if EXPERT > > ./init/Kconfig: bool "open by fhandle syscalls" if EXPERT > > ./init/Kconfig: bool "Posix Clocks & timers" if EXPERT > > ./init/Kconfig: bool "Enable support for printk" if EXPERT > > ./init/Kconfig: bool "BUG() support" if EXPERT > > ./init/Kconfig: bool "Enable ELF core dumps" if EXPERT > > ./init/Kconfig: bool "Enable full-sized data structures for core" if EXPERT > > ./init/Kconfig: bool "Enable futex support" if EXPERT > > ./init/Kconfig: bool "Enable eventpoll support" if EXPERT > > ./init/Kconfig: bool "Enable signalfd() system call" if EXPERT > > ./init/Kconfig: bool "Enable timerfd() system call" if EXPERT > > ./init/Kconfig: bool "Enable eventfd() system call" if EXPERT > > ./init/Kconfig: bool "Use full shmem filesystem" if EXPERT > > ./init/Kconfig: bool "Enable AIO support" if EXPERT > > ./init/Kconfig: bool "Enable IO uring support" if EXPERT > > ./init/Kconfig: bool "Enable madvise/fadvise syscalls" if EXPERT > > ./init/Kconfig: bool "Enable membarrier() system call" if EXPERT > > ./init/Kconfig: bool "Load all symbols for debugging/ksymoops" if EXPERT > > ./init/Kconfig: bool "Enable rseq() system call" if EXPERT > > ./init/Kconfig: bool "Enabled debugging of rseq() system call" if EXPERT > > ./init/Kconfig: bool "PC/104 support" if EXPERT > > ./init/Kconfig: bool "Enable VM event counters for /proc/vmstat" if EXPERT > > No. What you need is > * actually attempt to flip CONFIG_EXPERT (go to "General setup" submenu and > set "Configure standard kernel features (expert users)" there) > * check the resulting .config (or look at the items in question via > menuconfig) > * get enlightened > > Rob, if you are in a mood for a long wank, it's your business. But try to avoid > spraying the results over public lists. To elaborate: you are complaining about VT being treated the same way as e.g. ELF_CORE or UID16. Which might or might not be reasonable, but kconfig folks have nothing to do with that. Your complaint is basically that the same thing is forcing all of those on in default configs. Instead of having a separate ROB_WANTS_THOSE that would prop the rest, but not VT (and frankly, quite a bit of that rest is questionable for minimal setups). With ROB_WANTS_THOSE (or equivalent information) enshrined in the kernel tree for your convenience. Pardon me, but... why is that anyone else's problem?