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;
Subject: Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
References: <20190619223606.4575-1-denkenz@gmail.com>
 <20190619223606.4575-3-denkenz@gmail.com>
 <ec1ca95a5789f9001e89e603633b20316d687721.camel@sipsolutions.net>
 <7da9b924-78c7-ba72-fecc-a11700a34ff4@gmail.com>
 <44923833f1068e360b1f9534a9bbd37be41e4833.camel@sipsolutions.net>
 <427f488f-98f5-f888-f079-e2bbbb6eedf3@gmail.com>
 <144f36779085498bdc1b2f7ac0d0c267d431f51d.camel@sipsolutions.net>
 <cc4f1755ee5f27c72cbac344988bcb91a1a835f3.camel@sipsolutions.net>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <0b16aff6-7bd8-338f-2e52-f1011a914d2f@gmail.com>
Date:   Thu, 20 Jun 2019 18:51:36 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <cc4f1755ee5f27c72cbac344988bcb91a1a835f3.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi Johannes,

On 06/20/2019 03:21 PM, Johannes Berg wrote:
> On Thu, 2019-06-20 at 22:09 +0200, Johannes Berg wrote:
>>
>> Sure, but you don't really need to know *everything* about the events
>> right there ... you can already filter which ones you care about
>> (perhaps you know you never want to bind hwsim ones for example) and
>> then request data on those that you do need.
> 
> Btw, you can send a filter down when you do request the data, so you
> only get the data for the new wiphy you actually just discovered.

Yes, I know that.  I did help fix this ~3 years ago in commit 
b7fb44dacae04.  Nobody was using that prior, which really leads me to 
wonder what other userspace tools are doing for hotplug and how broken 
they are...

> 
> So realistically, vs. your suggestion of sending all of the data in
> multiple events, that just adds 2 messages (the request and the data you
> already had), which isn't nearly as bad as you paint it.

I never 'painted' the message overhead as 'bad'.  The performance 
overhead of this ping-pong is probably irrelevant in the grand scheme of 
things.  But I find the approach inelegant.

But really I'm more worried about race conditions that userspace has to 
deal with.  We already have the weird case of ATTR_GENERATION (which 
nobody actually uses btw).  And then we also need to dump both the 
wiphys and the interfaces separately, cross-reference them while dealing 
with the possibility of a wiphy or interface going away or being added 
at any point.   Then there's the fact that some drivers always add a 
default netdev, others that (possibly) don't and the possibility that 
the system was left in a weird state.

So from that standpoint it is far better to have the kernel generate 
atomic change events with all the info present than having userspace 
re-poll it when stuff might have changed in the meantime.

Going back to your 2 message point.  What about  sending the 'NEW_WIPHY' 
event with the info in labels 0-8.  And then another event type with the 
'rest' of the info.  And perhaps another feature bit to tell userspace 
to expect multiple events.  That would still end up being 2 messages and 
still be more efficient than the ping-pong you suggest.

Regards,
-Denis