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

[Borislav Petkov]

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)
--