[RFC 2/4] P2P: Handling single channel concurrency

[Jouni Malinen]

On Mon, Apr 09, 2012 at 12:44:54PM +0530, Jithu Jance wrote:
> Regarding the patch, do we really need to iterate through the interface
> list?. I was assuming that the wpas_drv_shared_freq implementation should
> take care of this.In case of virtual interfaces sharing a single PHY, the
> shared_freq handler should return the freq in use (STA associated freq/ GO
> operating freq).

The initial design of shared_freq() was really to use it only for the
case where there are virtual interfaces controlled by something else
than the current wpa_supplicant process (e.g., another wpa_supplicant
process or something completely different in case where P2P support is
managed by wpa_supplicant but a legacy station interface is run by
another software component). For driver_nl80211.c, my assumption was
that the same wpa_supplicant process would be used and as such, the
expectation was that shared_freq() would not actually be needed at all..

While there is now shared_freq() in driveR_nl80211.c, I'm not sure I
would really like to drop the concept of being able to figure out this
type of details through iteration of the internal data structure in the
core wpa_supplicant implementation.

> Again, this iteration check would be required for drivers which doesn't
> implement the shared_freq handler and still have shared virtual interfaces
> over a single PHY. I may be missing something here also. Please correct my
> understanding, if wrong. Apart from this doubt, everything else looks fine
> with the cleaned up version of the patch.

Well, that was the original assumption for driver_nl80211.c..

-- 
Jouni Malinen                                            PGP id EFC895FA