Message-ID: <555F83C4.1060908@gmail.com>
Date: Fri, 22 May 2015 15:30:12 -0400
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        "Luis R. Rodriguez" <mcgrof@suse.com>
CC: Takashi Iwai <tiwai@suse.de>, Paul Bolle <pebolle@tiscali.nl>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Borislav Petkov <bp@alien8.de>, Greg KH <gregkh@linuxfoundation.org>,
        "David S. Miller" <davem@davemloft.net>, clemens@ladisch.de,
        JBottomley@odin.com, David Airlie <airlied@linux.ie>,
        Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Marcel Holtmann <marcel@holtmann.org>,
        "Gustavo F. Padovan" <gustavo@padovan.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Mikael Starvik <starvik@axis.com>,
        Jesper Nilsson <jesper.nilsson@axis.com>,
        Imre Kaloz <kaloz@openwrt.org>, khalasa@piap.pl,
        Ohad Ben-Cohen <ohad@wizery.com>, Arnd Bergmann <arnd@arndb.de>,
        3chas3@gmail.com, Jiri Slaby <jslaby@suse.cz>,
        Bryan Wu <cooloney@gmail.com>, Richard Purdie <rpurdie@rpsys.net>,
        Jacek Anaszewski <j.anaszewski@samsung.com>, mcgrof@do-not-panic.com,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses
References: <1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com> <20150521222129.GI3689@pd.tnic> <20150522065346.GA23022@pd.tnic> <CAMuHMdVVi3Sf22wuNRU3U4LkvrKKSufC+wFxa78mtAWa48fK5w@mail.gmail.com> <1432282668.27695.24.camel@x220> <s5h7fs1gfxl.wl-tiwai@suse.de> <CAB=NE6WLsOoWOBwcHW5FC4k4GEtW-JWap52Zs34H-JZNtFxrhA@mail.gmail.com> <20150522175711.GE40101@dtor-ws> <20150522181924.GN23057@wotan.suse.de> <20150522185207.GG40101@dtor-ws>
In-Reply-To: <20150522185207.GG40101@dtor-ws>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000300060706000909090400"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 9245
Lines: 190

This is a cryptographically signed message in MIME format.

--------------ms000300060706000909090400
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

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@suse.de> 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@alien8.de> w=
rote:
>>>>>>>> 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 uns=
et but
>>>>>>>> if you want to boot-test those kernels, you will artificially fa=
il 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 specia=
l case
>>>>>> EXPERT in randconfig. But that would make randconfig builds less u=
seful.
>>>>>> That's a separate issue, anyhow.)
>>>>>
>>>>> But FW_LOADER is a tristate, so it might be inconsistent if selecte=
d
>>>>> 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 wh=
en
>>>> folks enable EXPERT?
>>>
>>> Yes.
>>>
>>> dtor@dtor-ws:~/kernel/master$ grep -r CONFIG_EXPERT /boot/config*
>>> /boot/config-3.13.0-49-generic:CONFIG_EXPERT=3Dy
>>> /boot/config-3.13.0-52-generic:CONFIG_EXPERT=3Dy
>>>
>>> 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=20
patches and configuration layered on top.  IMHO though, they really do=20
have a good excuse for enabling CONFIG_EXPERT (namely, they have=20
absolute control over pretty much the entire system, and run on=20
specialized hardware).
>>
>> Either way SUSE kernels also have EXPERT=3Dy as well.  Would not be su=
rprised if
>> other major distributions also have EXPERT=3Dy.
>
> 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 ki=
nd
>> 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%=20
have EXPERT=3Dy for exactly this reason, namely, they want finer control =

over driver options, and don't do anything to the options under the=20
EXPERT menu.  Personally this is one of two reasons that I use EXPERT=3Dy=
,=20
the other being disabling the handful of deprecated syscalls at the top=20
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 rig=
ht 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 o=
n"?
>
> 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 al=
l
> are "experts".
>
Based on this, maybe the EXPERT stuff should be subdivided into driver=20
options, and core API options under separate config options.


--------------ms000300060706000909090400
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGuDCC
BrQwggScoAMCAQICAxBuVTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNTAz
MjUxOTM0MzhaFw0xNTA5MjExOTM0MzhaMGMxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEj
MCEGCSqGSIb3DQEJARYUYWhmZXJyb2luN0BnbWFpbC5jb20xIjAgBgkqhkiG9w0BCQEWE2Fo
ZW1tZWxnQG9oaW9ndC5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCdD/zW
2rRAFCLnDfXpWxU1+ODqRVUgzHvrRO7ADUxRo1CBDc3JSX5TIW2OGmQ3DAKGOACp8Z0sgxMc
B05tzAZ/M7m4jajVrwwdVCdrwVGxTdAai7Kwg4ZCVfyMVhcwo8R2eW3QahBx34G0RKumK9sZ
ZQSQ+zULAzpY6uz7T1sAk/erMoivRXF6u8WvOsLkOD1F/Xyv1ZccSUG5YeDgZgc0nZUBvyIp
zXSHjgWerFkrxEM3y2z/Ff3eL1sgGYecV/I1F+I5S01V7Kclt/qRW10c/4JEGRcI1FmrJBPu
BtMYPbg/3Y9LZROYN+mVIFxZxOfrmjfFZ96xt/TaMXo8vcEKtWcNEjhGBjEbfMUEm4aq8ygQ
4MuEcpJc8DJCHBkg2KBk13DkbU2qNepTD6Uip1C+g+KMr0nd6KOJqSH27ZuNY4xqV4hIxFHp
ex0zY7mq6fV2o6sKBGQzRdI20FDYmNjsLJwjH6qJ8laxFphZnPRpBThmu0AjuBWE72GnI1oA
aO+bs92MQGJernt7hByCnDO82W/ykbVz+Ge3Sax8NY0m2Xdvp6WFDY/PjD9CdaJ9nwQGsUSa
N54lrZ2qMTeCI9Vauwf6U69BA42xgk65VvxvTNqji+tZ4aZbarZ7el2/QDHOb/rRwlCFplS/
z4l1f1nOrE6bnDl5RBJyW3zi74P6GwIDAQABo4IBWTCCAVUwDAYDVR0TAQH/BAIwADBWBglg
hkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg
b3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYDVR0PAQH/BAQDAgOoMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4
QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9y
ZzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2VydC5vcmcvcmV2b2tlLmNybDA0
BgNVHREELTArgRRhaGZlcnJvaW43QGdtYWlsLmNvbYETYWhlbW1lbGdAb2hpb2d0LmNvbTAN
BgkqhkiG9w0BAQ0FAAOCAgEAGvl7xb42JMRH5D/vCIDYvFY3dR2FPd5kmOqpKU/fvQ8ovmJa
p5N/FDrsCL+YdslxPY+AAn78PYmL5pFHTdRadT++07DPIMtQyy2qd+XRmz6zP8Il7vGcEDmO
WmMLYMq4xV9s/N7t7JJp6ftdIYUcoTVChUgilDaRWMLidtslCdRsBVfUjPb1bF5Ua31diKDP
e0M9/e2CU36rbcTtiNCXhptMigzuL3zJXUf2B9jyUV8pnqNEQH36fqJ7YTBLcpq3aYa2XbAH
Hgx9GehJBIqwspDmhPCFZ/QmqUXCkt+XfvinQ2NzKR6P3+OdYbwqzVX8BdMeojh7Ig8x/nIx
mQ+/ufstL1ZYp0bg13fyK/hPYSIBpayaC76vzWovkIm70DIDRIFLi20p/qTd7rfDYy831Hjm
+lDdCECF9bIXEWFk33kA97dgQIMbf5chEmlFg8S0e4iw7LMjvRqMX3eCD8GJ2+oqyZUwzZxy
S0Mx+rBld5rrN7LsXwZ671HsGqNeYbYeU25e7t7/Gcc6Bd/kPfA+adEuUGFcvUKH3trDYqNq
6mOkAd8WO/mQadlc3ztS++XDMhmIpfBre9MPAr6usqf+wc+R8Nk9KLK39kEgrqVfzc/fgf8L
MaD4rHnusdg4gca6Yi+kNrm99anw7SwaBrBvULYBp7ixNRUhaYiNW4YjTrYxggShMIIEnQIB
ATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v
cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW
EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDEG5VMAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUyMjE5MzAxMlowIwYJKoZIhvcNAQkE
MRYEFAMmja7HoPJJx03cWhREBZ9LwF+NMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq
MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC
AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYD
VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT
GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj
ZXJ0Lm9yZwIDEG5VMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB
MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2ln
bmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDEG5V
MA0GCSqGSIb3DQEBAQUABIICAAxXe0pJ/XEQvNzzQl9iDs1YVUsZqYL6ZLyEp97ofjxQhkNI
uRK/cOB6fR64Liz2zwqAtcQADrhom6QtERo4bmxjwrlVT6zzMUbO/ammzflG+gbPTLvkBrxH
YwMtYMje5TAiSyqiU+/vxX4rXBbi6vy0Cgx8KmwXKSttv6wVeVm0q+dRLNlEXHq5w9iGY4PN
StyAAvfDBAEihQj8/Kz98h1+B6SB5tEEiZmS8lws2gynccXYkOTCfNLWws8cIQgjRwi2afFf
dQI5Ly9ZlOkbIuUOCXqyH1WtFSXgtb1U0NBczDHDzqH6nnrxj21q3xJ3H7QrfuvHWS2X9NxF
r9HlVEX0dGd473zr3SJs/VCn+8QiORQNhBUOr1v1jNeHJHdV/jfKDT93LFhQL7zmmfY07Hse
aKW8STPh0vtO4JXUm+++X4ASextnsjrIvrkgqKTC5AFPVY+hCkNo2zdp0d0535PHFwFtMojg
x/cTeoR4M6TF5hR+43sl9Qfd6hXTSpz/TAIl4n5CCQGfgdFIOS7nPnoxCu7JsOowm1o/WxUa
YUHvmVOAWGQRtuWqf62J+w3yltL03Pm6WdT3Koi2wI17QR52RykwmtqmdHjKJOvrdHdZWHZq
20lSZ3J7XbpcuF3OSICZkzEKfK7lYj4GvoV8kcbgSCIxcRRRGTd+7sA005JGAAAAAAAA
--------------ms000300060706000909090400--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/