From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757911AbcASJoK (ORCPT ); Tue, 19 Jan 2016 04:44:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:39179 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757844AbcASJoB (ORCPT ); Tue, 19 Jan 2016 04:44:01 -0500 Date: Tue, 19 Jan 2016 10:43:35 +0100 From: Borislav Petkov To: Ingo Molnar Cc: Linus Torvalds , Greg Kroah-Hartman , Andrew Morton , Michal Marek , =?utf-8?B?TcOlbnMgUnVsbGfDpXJk?= , Markus Trippelsdorf , Thomas Voegtle , linux-kernel@vger.kernel.org, x86-ml , Peter Zijlstra , Thomas Gleixner , Jiri Olsa , Arnaldo Carvalho de Melo , =?utf-8?B?RnLDqWTDqXJpYw==?= Weisbecker Subject: Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig) Message-ID: <20160119094335.GB15071@pd.tnic> References: <568FB028.1030706@suse.cz> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160119082022.GB18237@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 19, 2016 at 09:20:22AM +0100, Ingo Molnar wrote: > 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... Tell me about it. SCSI SAS recent breakage case-in-point... > 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. Yeah, so I have a different idea how to fix it. I'm going to drop both depends on BLK_DEV_INITRD select FW_LOADER and make it build with or without them enabled so that people are free to do whatever they want and not get the feeling that I'm forcing shit down their throats. HOWEVER(!), this, IMHO, won't help with the normal users because then they'd have to read Kconfig: + The preferred method to load microcode is described in + Documentation/x86/early-microcode.txt. For that you need to enable + CONFIG_BLK_DEV_INITRD in order for the loader to be able to scan the + initrd for microcode blobs. + Alternatively, you can build-in the microcode into the kernel. For + that you need the functionality behind CONFIG_FW_LOADER. and figure out what to do exactly to have microcode applied. And this is crap, IMO. It should JustWork. I dunno, maybe I should do a separate config option which let people choose between FW_LOADER and BLK_DEV_INITRD if CONFIG_MICROCODE is enabled. I need to hack it in and see what it becomes. Anyway, I'm just giving my example here as a POV for the discussion. > 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'm working on untangling CONFIG_MICROCODE from BLK_DEV_INITRD so you won't need to touch the Kconfig. See above. > 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. Yeah, people complained that they don't want to run with initrds. > 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. CONFIG_EXPERT_MORE ? > From my own randconfig testing I can give a core list of must-have > kernel options, without which most distros (Fedora, RHEL, Ubuntu, > SuSE) won't boot properly: > > +config FORCE_MINIMALLY_SANE_CONFIG > + bool > + default y ... > And yes, many of these options are members of the 'SystemD > debuggability Hall Of Shame'... It cost me many, many days of painful > config-bisection to figure the often obscure dependencies out, so we > might as well upstream this information. > > Many braincells died to bring us this information! I know *exactly* what you're talking about! Yeah, so having an option select *sane* settings but leaving the possibility to change that for expert users makes sense. ... > The idea is that if you have this option enabled, the rest of kernel > config should be 'fool proof' - or at least failures should be a > lot more obvious (such as a missing hardware driver or a missing > filesystem driver). Yap. ... > Thoughs? Sounds like a good idea to me. Thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --