Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

[Markus Trippelsdorf <markus@trippelsdorf.de>]

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 <bp@suse.de> wrote:
> 
> > From: Borislav Petkov <bp@suse.de>
> > 
> > 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.

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. 

-- 
Markus