lkml.org 
[lkml]   [2016]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

    * Markus Trippelsdorf <markus@trippelsdorf.de> 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 <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.

    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

    \
     
     \ /
      Last update: 2016-01-19 10:21    [W:3.715 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site