Re: [PATCH 0/5] Improve wireless netdev detection

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2016-07-07 at 02:08 -0500, Denis Kenzior wrote:
> The current mechanism to detect hot-plug / unplug of wireless devices
> is
> somewhat arcane.  One has to listen to NEW_WIPHY/DEL_WIPHY events
> over
> nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
> somehow find a correlation between these events.  This involves
> userspace
> sending GET_INTERFACE or GET_WIPHY commands to the kernel, which
> incurs
> additional roundtrips.
> 
> This patch series proposes that NEW_INTERFACE and DEL_INTERFACE
> events are
> always emitted, regardless of whether a netdev was added/removed by
> the
> driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.
> 
> One side effect of this approach is that multiple
> NEW_INTERFACE/DEL_INTERFACE
> events might be generated for P2P interfaces.  Once when a wdev is
> created
> or destroyed, and once when the associated p2p netdev is connecte or 
> disconnected.  

I think you got some things mixed up. Are you talking of P2P GO/client
interfaces, which have netdevs, but are really the same as AP/BSS
client and thus the issue here would affect the others? Or are you
talking about the P2P-Device wdev? but that has no netdev.

> It is likely that only the caller of P2P oriented
> NEW_INTERFACE / DEL_INTERFACE commands is interested in the status of
> these
> operations.  E.g. the caller is / should be using SOCKET_OWNER
> attribute.
> Thus one possibility is to not emit NEW_INTERFACE/DEL_INTERFACE
> events in
> such cases.
> 

The breaking up of patches is also confusing. You seem to be
introducing things in the first, then breaking them again, and then
fixing them?

Couldn't the whole thing be done in one or maybe two (new/del)
patch(es)?

(You obviously also need to sign off your patches, see the kernel
Documentation/)

johannes