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
