Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5324447ybe; Tue, 10 Sep 2019 01:48:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqyeOkhY1BI0Ed/xRNgn04lkEPK84VKMle8A/608PGff+4hP0VTrR0xT5oFNg6eZg1GGo14s X-Received: by 2002:a17:906:2929:: with SMTP id v9mr23315899ejd.108.1568105292343; Tue, 10 Sep 2019 01:48:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568105292; cv=none; d=google.com; s=arc-20160816; b=MyNZEDqEZjr7aDLFMMHAjxk8CpOmqoUyX1knydZexJAQ6BiL5MCqLkFbWaLj84d+sz 7Jru+8DteIB3TnaN9+N1jj7kCr3Gw4e9gnUv7jXJiOcZnL6JZ91hLRWQ6L9mUZxF270H U9dELTMYayJWRm63c2bowcktLfukzEvds2dzQqDqRX8dcQ6itgqJZsUvChYq4VZy9HLb pk7ZD+iX7UCfCt6VxxaHgndkvGCCvyVbRdKBGyUg+3kqIke6eerTdx8zFjE+0xnJcvw8 dh0avvsEs8uDwU0d7q5DQFfzljB776LtP9XLbSpjNUZ0eFvvyDqFAH9l7/UAEefLJ7x8 Jlkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=gqRCaepI+RK69swYXDuFpAsSo6xTm+y38LlbQGyZbc8=; b=oReHtecSQiuHhjMrKlUQz9AjgUS/s8P7GqI2jBh2/aAItB0IVJtz+DDfZyzISXvQyp I0eLfFgsHZExU4RkPRUJiupI0qJ1MT0zg5itlP08LkH1XgyqUe6n1auNniReVc4pux/W czmHNmnh3QSl8nkiVTKJMxgbxd4SSPw0Dd30lailkUGq8+v6+dHG3hHPbdXhAmrfCvd2 xMF2tJVxkcXsEruUHJELNEFV4Fl+tiUwLWchdIoS2nZug7JYEY+34gwfhaBhe+dXXaMG SIMrrfQ8BeFx2qfocojl5DwASHgVLHCE4DLJPXwzB//8nfkB9yPH/zHYFypEGZGo+v3l OfSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l22si2487639ejn.20.2019.09.10.01.47.48; Tue, 10 Sep 2019 01:48:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388763AbfIIPpK (ORCPT + 99 others); Mon, 9 Sep 2019 11:45:10 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:33806 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729326AbfIIPpK (ORCPT ); Mon, 9 Sep 2019 11:45:10 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i7LqW-0000DN-Ku; Mon, 09 Sep 2019 17:44:52 +0200 Message-ID: <6f3487136e71afbd4d2b621551ee14e68c4cc1ab.camel@sipsolutions.net> Subject: Re: [PATCH v2] net: enable wireless core features with LEGACY_WEXT_ALLCONFIG From: Johannes Berg To: Mark Salyzyn , Greg KH Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, "David S. Miller" , Marcel Holtmann , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, stable@vger.kernel.org Date: Mon, 09 Sep 2019 17:44:51 +0200 In-Reply-To: (sfid-20190909_162434_303033_C0355249) References: <20190906192403.195620-1-salyzyn@android.com> <20190906233045.GB9478@kroah.com> (sfid-20190909_162434_303033_C0355249) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 2019-09-09 at 07:24 -0700, Mark Salyzyn wrote: > > > How is this patch applicable to stable kernels??? I'm not sure I even buy the arguments to get it into the regular kernel. > B) there is a shortcoming in _all_ kernel versions with respect to > hidden configurations options like this, hoping to set one precedent in > how to handle them if acceptable to the community. This really is the only argument, I think, but I don't really see it as a shortcoming. The kernel is handling this properly, after all, with respect to itself. You just have issues with out-of-tree modules. And while it is true, setting that precedent might ultimately mean we'll end up with ~80 (**) new Kconfig options in net/ alone ... That's certainly *NOT* a precedent I want to set nor the way I want to see this handled, when we already get complaints that we're adding too many Kconfig options (and those are ones we really do need). Obviously, nothing stops you from putting this into your kernel (and I guess you already are), but I don't really see how it benefits us as a kernel community. > E) Timely discussion item for LPC? Perhaps you should indeed drive that discussion there, this really is bigger than this particular wireless feature. At the very least, to avoid Kconfig complexity explosion, add a single new config OPTIONS_FOR_OUT_OF_TREE_MODULES bool "..." depends on EXPERT help ... and make LEGACY_WEXT_ALLCONFIG depend on that. But if you're honest and obvious about it like that, I have a hard time seeing you get that into the tree past Greg or Linus... Also, you probably know this, but in this particular case you really should just get rid of your wext dependencies ... this stuff is literally decades old, and while that isn't necessarily a bad thing, it also has issues that have been known for a decade or so that simply cannot be solved. (**) git grep "bool$" and "tristate$" in Kconfig files under net/ yields a bit more, but here you already set 5, who knows. Still, even if it's only 20 in the end that's too much. johannes