From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79B55C4CEC9 for ; Fri, 13 Sep 2019 18:49:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4585B20830 for ; Fri, 13 Sep 2019 18:49:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389907AbfIMStt (ORCPT ); Fri, 13 Sep 2019 14:49:49 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:59706 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389736AbfIMStt (ORCPT ); Fri, 13 Sep 2019 14:49:49 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i8qdf-0006el-Fh; Fri, 13 Sep 2019 20:49:47 +0200 Message-ID: Subject: Re: [RFC 0/4] Allow live MAC address change From: Johannes Berg To: James Prestwood , linux-wireless@vger.kernel.org Date: Fri, 13 Sep 2019 20:49:45 +0200 In-Reply-To: <896183390a396e8e0508622eceb3664effcb3c30.camel@gmail.com> (sfid-20190911_212249_094118_78051519) References: <20190904191155.28056-1-prestwoj@gmail.com> (sfid-20190904_221357_305070_478BF6CA) <4c43ea6a74cacc61184bc5b1387fecaa40711369.camel@gmail.com> (sfid-20190911_175613_316165_C021A0FB) <4909a428ee6fef2bf8b0e61841bc88062f534b13.camel@sipsolutions.net> <896183390a396e8e0508622eceb3664effcb3c30.camel@gmail.com> (sfid-20190911_212249_094118_78051519) 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 Wed, 2019-09-11 at 12:20 -0700, James Prestwood wrote: > I see what your saying, but theses kind of state changes are all over > the place in other APIs, and undocumented: One example is > SCAN_FLAG_FLUSH clearing out the scanning state for all other > processes. Scanning always changes scan list state? > I'm sure I could find more. If we documented this attribute > and behavior I don't see an issue. But I'm sure you could actually find an example :-) That doesn't really mean it's the *right* thing to do though, IMHO. Also, who says that this is the only thing? Next up, somebody wants to randomize the MTU? Ok, probably not, but you could pick a random other rtnetlink attribute and have nl80211 set it. Where do we stop? Thinking this to the extreme - why not add an rtnetlink message interpreter into this code? ;-) Sure, none of that is really seriously likely to happen, but I'm really not convinced we (more or less arbitrarily) need many ways of doing the same thing in the kernel. Either way, regardless of that discussion, I think it'd be good if you could repost the patches for just the "quick win" that we can all agree on, and then we can get those reviewed and into the tree before we need to continue this discussion; after all, while we're discussing saving about 3 milliseconds, you're still wasting around 280 :-) (and the easy one can be done without affecting the other, just need to reorder the patches and split them a bit differently) johannes