linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
Date: Thu, 20 Jun 2019 18:51:36 -0500	[thread overview]
Message-ID: <0b16aff6-7bd8-338f-2e52-f1011a914d2f@gmail.com> (raw)
In-Reply-To: <cc4f1755ee5f27c72cbac344988bcb91a1a835f3.camel@sipsolutions.net>

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

  reply	other threads:[~2019-06-20 23:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 22:36 [PATCH 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL Denis Kenzior
2019-06-19 22:36 ` [PATCH 2/3] nl80211: Limit certain commands to interface owner Denis Kenzior
2019-06-27  8:55   ` [nl80211] d8572a564d: assertion_failed kernel test robot
2019-06-19 22:36 ` [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY Denis Kenzior
2019-06-20  6:58   ` Johannes Berg
2019-06-20 16:16     ` Denis Kenzior
2019-06-20 19:17       ` Johannes Berg
2019-06-20 20:05         ` Denis Kenzior
2019-06-20 20:09           ` Johannes Berg
2019-06-20 20:21             ` Johannes Berg
2019-06-20 23:51               ` Denis Kenzior [this message]
2019-06-20 20:35             ` Denis Kenzior
2019-06-20  7:50 ` [PATCH 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b16aff6-7bd8-338f-2e52-f1011a914d2f@gmail.com \
    --to=denkenz@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).