Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

From: Austin S Hemmelgarn
Date: Fri May 22 2015 - 15:30:33 EST


On 2015-05-22 14:52, Dmitry Torokhov wrote:
On Fri, May 22, 2015 at 08:19:24PM +0200, Luis R. Rodriguez wrote:
On Fri, May 22, 2015 at 10:57:11AM -0700, Dmitry Torokhov wrote:
On Fri, May 22, 2015 at 10:43:12AM -0700, Luis R. Rodriguez wrote:
On Fri, May 22, 2015 at 1:44 AM, Takashi Iwai <tiwai@xxxxxxx> wrote:
At Fri, 22 May 2015 10:17:48 +0200,
Paul Bolle wrote:

On Fri, 2015-05-22 at 09:11 +0200, Geert Uytterhoeven wrote:
On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
One thing I forgot last night: what about randconfigs? All that
functionality which selects FW_LOADER, won't boot anymore, right? I
mean, there are provisions to build fine even with FW_LOADER unset but
if you want to boot-test those kernels, you will artificially fail due
to missing request_firmware* things...

Luis also tried to explain to me that disabling FW_LOADER shouldn't make
the build fail. (And, of course, we could decide to not care about
randconfig builds that have EXPERT set. Maybe we could even special case
EXPERT in randconfig. But that would make randconfig builds less useful.
That's a separate issue, anyhow.)

But FW_LOADER is a tristate, so it might be inconsistent if selected
randomly? Luis' patch doesn't add depends but just removes select.

We could go both ways, either remove the "select" or replace it with
"depends on". As you note keeping the "depends on" ensures run time
sanity for the possible tristate mismatches, but this is an EXPERT
concern. The crux of what option to go with is:

Should we concern ourselves with run time configuration issues when
folks enable EXPERT?

Yes.

dtor@dtor-ws:~/kernel/master$ grep -r CONFIG_EXPERT /boot/config*
/boot/config-3.13.0-49-generic:CONFIG_EXPERT=y
/boot/config-3.13.0-52-generic:CONFIG_EXPERT=y

This is distro config and that is what many people use as a base for
their own configs.

Smells Ubuntu'ish, and hence ChromeOS'ish :)

Yes, this coming from Ubuntu, but ChromeOS is closer to Gentoo if
anything I'd say ;)

Technically, ChromeOS _is_ Gentoo, just with a bunch of third party patches and configuration layered on top. IMHO though, they really do have a good excuse for enabling CONFIG_EXPERT (namely, they have absolute control over pretty much the entire system, and run on specialized hardware).

Either way SUSE kernels also have EXPERT=y as well. Would not be surprised if
other major distributions also have EXPERT=y.

Right, I believe Fedora has it set as well.

I'm pretty certain that Fedora does, and that Arch does as well.

OK so we obviously care about EXPERT run time issues then, seems to kind
of defeat the purpose of EXPERT though, no? Makes me wonder what major options
are under EXPERT which most distros need.

Not major, rather tweaking the driver sets. Like expert V4L or HID
configs.

Of the people I know personally who build their own kernels, about 80% have EXPERT=y for exactly this reason, namely, they want finer control over driver options, and don't do anything to the options under the EXPERT menu. Personally this is one of two reasons that I use EXPERT=y, the other being disabling the handful of deprecated syscalls at the top of the list (and disabling AIO when I'm building embedded systems).
Also, are there no other runtime
configuration options tucked under EXPERT that we *do not* resolve right now?
Or should all be taken care of? If not then we are being inconsistent.
Both of these are side topics -- but since I have a feeling this might come
up again, it may be worth evaluation.

Following on topic: such distro configs would never have FW_LOADER as n or
m, though right? Is that sufficient for us to drop the select and not apply
the "depends on" replacement ? Or do we want to stick to the "depend on"?

But the user who is not expecrt might drop it. The premise was "only
experts would have CONFIG_EXPERT and thus we do not care about
breakage". But if people use distro configs as a starting point they all
are "experts".

Based on this, maybe the EXPERT stuff should be subdivided into driver options, and core API options under separate config options.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature