[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yw1xbn8hsqf7.fsf@unicorn.mansr.com>
Date: Tue, 19 Jan 2016 12:29:48 +0000
From: Måns Rullgård <mans@...sr.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Borislav Petkov <bp@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Marek <mmarek@...e.cz>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Thomas Voegtle <tv@...96.de>, linux-kernel@...r.kernel.org,
x86-ml <x86@...nel.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Jiri Olsa <jolsa@...hat.com>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y
Ingo Molnar <mingo@...nel.org> writes:
> 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?
The problem with *any* approach involving Kconfig is that it still
leaves users free to load microcode whenever they want, even if they're
not supposed to. Doing so apparently works correctly (almost) every
time (how does it fail if it does?), and no warnings are issued to
suggest it might be a bad idea. Force-enabling BLK_DEV_INITRD isn't
going to make anyone change their boot scripts. Many might not even
notice that it got silently enabled. So what purpose does it serve to
play games with the config when it has no actual impact on the usage of
the driver?
I'd also like to get a coherent answer to why microcode update is
preferably done from an initrd as opposed to shortly after mounting a
regular disk. My systems seem perfectly happy doing the latter.
--
Måns Rullgård
Powered by blists - more mailing lists