From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757667AbcASIyT (ORCPT ); Tue, 19 Jan 2016 03:54:19 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33445 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757324AbcASIyQ (ORCPT ); Tue, 19 Jan 2016 03:54:16 -0500 Date: Tue, 19 Jan 2016 09:54:12 +0100 From: Ingo Molnar To: Markus Trippelsdorf Cc: Borislav Petkov , Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Michal Marek , =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , Thomas Voegtle , linux-kernel@vger.kernel.org, x86-ml , Peter Zijlstra , Thomas Gleixner , Jiri Olsa , Arnaldo Carvalho de Melo , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker Subject: Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig) Message-ID: <20160119085412.GA27291@gmail.com> References: <20160108133725.GH14673@pd.tnic> <568FCC45.1010301@suse.cz> <20160111194311.GF4686@pd.tnic> <20160111205945.GH4686@pd.tnic> <20160111211712.GI4686@pd.tnic> <20160114184350.GB12109@pd.tnic> <20160119082022.GB18237@gmail.com> <20160119084034.GA321@x4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160119084034.GA321@x4> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Markus Trippelsdorf wrote: > On 2016.01.19 at 09:20 +0100, Ingo Molnar wrote: > > > > ( I've Cc:-ed Linus, Greg and Andrew, to see whether doing something like what I > > suggest below in the x86 architecture would be acceptable. ) > > > > * Borislav Petkov wrote: > > > > > From: Borislav Petkov > > > > > > Thomas Voegtle reported that doing oldconfig with a .config which has > > > CONFIG_MICROCODE enabled but BLK_DEV_INITRD disabled prevents the > > > microcode loading mechanism from being built. > > > > > > Add a short script which hooks into the "make oldconfig" handling and > > > sanity-checks the config file for that discrepancy. It issues a message > > > which should hopefully sensitize the user to that issue and point her > > > into the right direction. > > > > So it would be much better to just do such things automatically, and only allow > > 'safe' combination of options - without the user having to do anything. > > > > The guiding principle is: kernel configuration is (still...) our worst barrier of > > entry for new users/developers, and kernel configuration still sucks very much > > from a UI point of view. > > > > In fact our kernel configuration UI and workflow is still so bad that it's an > > effort to stay current even with a standalone and working .config, even for > > experienced kernel developers... > > > > Adding a (somewhat hacky) post processing script and forcing users to read > > something 99% of them does not have a clue about is a step in the wrong direction, > > IMHO. > > > > So can we do something more intelligent instead, such as modifying the Kconfigs in > > a way that it's not possible to have CONFIG_MICROCODE enabled while BLK_DEV_INITRD > > is disabled? > > > > I'd be fine with a 'select BLK_DEV_INITRD' for example. If people doing super > > specialized setups disagree because they really need that nonsensical combination > > of config options, they can complain and provide a better solution. > > > > In fact on x86 I'd suggest we go farther than that and add a core set of selects > > that can be disabled only through a sufficiently scary "I really know I'm doing > > something utmost weird" (and default disabled) config option. > > This is essential. Because, believe it or not, there are still users out > there that don't use systemd. And to force enable totally superfluous > config options for them would be bad. Well, I think the argument I raised later on is important: > > [...] from a usability POV it's _much_ better to have a few more options > > enabled in a .config of thousands of entries, than to accidentally have the > > one option not enabled that your user-space somehow critically depends on ... I.e. the costs of quirks are _massively_ assymetric: having an extra system call or compat option quirk enabled is essentially unmeasurable for those who don't technically need them, while it can be a big and hard to debug show-stopper for others. 'default y' was supposed to cover such cases, but arguably it's too opaque, I think we need a separate, more obvious layer - such as the CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y option I suggested. > So, as long as this "systemd config" could be easily disabled, your approach > looks fine and would definitely be helpful to many mainstream distro users. It sure can be easily disabled, that's a given. The key point is that I'd like "naively configured" kernels to work on just about any Linux distro that allow kernel testing - so the superset of all quirks should be included - as long as enabling a quirk does not break things (and none of the ones I listed do as far as I've tested). Thanks, Ingo