From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-qk0-x242.google.com ([2607:f8b0:400d:c09::242]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f8iTP-00015T-Qm for ath10k@lists.infradead.org; Wed, 18 Apr 2018 08:29:54 +0000 Received: by mail-qk0-x242.google.com with SMTP id b39so903598qkb.5 for ; Wed, 18 Apr 2018 01:29:40 -0700 (PDT) Subject: Re: [PATCH 2/2] ath10k: support MAC address randomization in scan References: <1522379640-6442-1-git-send-email-cjhuang@codeaurora.org> <1522379640-6442-3-git-send-email-cjhuang@codeaurora.org> <20180412205954.GA34456@rodete-desktop-imager.corp.google.com> <877epbs5v7.fsf@kamboji.qca.qualcomm.com> <5AD11D7C.1030603@broadcom.com> <242be71eb87140c9560163c4000255b2@codeaurora.org> <8736zvqtcw.fsf@kamboji.qca.qualcomm.com> <20180417002854.GA186697@rodete-desktop-imager.corp.google.com> <5AD5AEB5.1040808@broadcom.com> <20180417160715.GA255263@rodete-desktop-imager.corp.google.com> <5AD66BD9.4000706@broadcom.com> From: Arend van Spriel Message-ID: <5AD701F0.20504@broadcom.com> Date: Wed, 18 Apr 2018 10:29:36 +0200 MIME-Version: 1.0 In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Dan Williams , Brian Norris Cc: Johannes Berg , cjhuang@codeaurora.org, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Kalle Valo + Johannes (to confirm/correct my understanding regarding "supported commands") On 4/18/2018 4:35 AM, Dan Williams wrote: > On Tue, 2018-04-17 at 15:26 -0700, Brian Norris wrote: >> On Tue, Apr 17, 2018 at 2:49 PM, Arend van Spriel >> wrote: >>> On 4/17/2018 6:07 PM, Brian Norris wrote: >>>> On Tue, Apr 17, 2018 at 10:22:13AM +0200, Arend van Spriel wrote: >>>>> I believe checking command support is not really recommended. >>>>> Instead, you >>>>> better check NL80211_ATTR_SCHED_SCAN_MAX_REQS being non-zero >>>>> (since kernel >>>>> 4.12 that is). >>>> >>>> >>>> Why not? Command support checking is what wpa_supplicant is >>>> doing. >>> >>> >>> That's not really a good argument. A couple (or more) years ago >>> wpa_supplicant was not doing nl80211 but wext and some other using >>> driver private ioctls, but that did not make it the best approach. >> >> I see what you're saying (though your comparison doesn't seem that >> fair either; private ioctls are nothing like a well-defined nl80211 >> support list), and I'm totally good on looking at the new flag >> eventually. But you still haven't answered my question ("why not?"). >> Is there a problem with the "supported commands" list? My understanding is that in general the "supported commands" list is not well-maintained. Not every nl80211 command is represented in the list so user-space can not know whether it is missing or not supported. For this particular START_SCHED_SCAN command it can be used still and indeed probably for a long time. I just wanted to point out that it is not recommended for new user-space functionality. >>> The START_SCHED_SCAN command is indeed still provided to user- >>> space: >> >> And as I see it, it probably needs to be for essentially forever. Or >> at least a significant amount of time after wpa_supplicant stops >> relying on it. (Hint: it's still using it today, with no reference to >> NL80211_ATTR_SCHED_SCAN_MAX_REQS.) There's a reason the kernel has >> ABI >> guarantees. I suspect you only get a chance to rewrite the world >> (WEXT >> -> nl80211) a few times in the life of kernel ABIs. > > It sometimes feels like wpa_supplicant gets treated as a static entity > that can never be changed. In fact, send a patch to Jouni implementing > the best practice, with a fallback to preserve compat for old kernels, > and I'm sure he'd entertain it. Just because the supplicant does > something a certain way, doesn't mean it's the *best* way, but it too > evolves. I was actually considering to do that. The netlink messages are easily checked for presence of an attribute so deciding on whether to use the fallback is trivial. Regards, Arend _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k