Re: [PATCH 0/5] Improve wireless netdev detection
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Improve wireless netdev detection
Hi Johannes, On 07/08/2016 05:32 AM, Johannes Berg wrote: 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. Apologies, I've only been looking at the kernel side for several days, so my understanding is still incomplete. I was looking at mac80211/iface.c: ieee80211_if_add() which seems to handle NL80211_IFTYPE_P2P_DEVICE specially by not creating/registering a net_device object. For some reason I thought that this object was registered somewhere later, but my understanding was incorrect. So the entire 'side effect' paragraph above does not apply. Are you okay with the general approach? Are there any locking issues I might be overlooking? 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? Sorry, this was meant to be posted as an RFC. First patch just introduces a notification utility. The rest of the patches were broken up for ease of review. Couldn't the whole thing be done in one or maybe two (new/del) patch(es)? Sure, I can squash them together however you like. (You obviously also need to sign off your patches, see the kernel Documentation/) Apologies, still working the kinks out of my environment setup. Regards, -Denis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Improve wireless netdev detection
On Fri, 2016-07-08 at 10:22 -0500, Denis Kenzior wrote: > > Apologies, I've only been looking at the kernel side for several > days, so my understanding is still incomplete. > > I was looking at mac80211/iface.c: ieee80211_if_add() which seems to > handle NL80211_IFTYPE_P2P_DEVICE specially by not > creating/registering a > net_device object. For some reason I thought that this object was > registered somewhere later, but my understanding was incorrect. So > the entire 'side effect' paragraph above does not apply. Ok, makes sense. > Are you okay with the general approach? I see no issues with sending these events out. I'd like them to actually be reliable (if present) though, not double as you'd implied - but I didn't really understand in which cases you were expecting issues, was it only P2P-Device? > Are there any locking issues I > might be overlooking? Not that I'm aware of. All of the netdev/wdev handling should be protected by RTNL. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Improve wireless netdev detection
Hi Johannes, >> Are you okay with the general approach? I see no issues with sending these events out. I'd like them to actually be reliable (if present) though, not double as you'd implied - but I didn't really understand in which cases you were expecting issues, was it only P2P-Device? That seems to be the only special case. At least I didn't find any other situations where a NEW_INTERFACE command can be called without a corresponding net_device being created. Are there any locking issues I might be overlooking? Not that I'm aware of. All of the netdev/wdev handling should be protected by RTNL. That was my understanding as well. Thanks. Okay, let me spin up a v2 with patches 2+3 and 4+5 squished together. Or do you want one big patch? Regards, -Denis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
