[RFC 2/4] P2P: Handling single channel concurrency
Thu Jun 14 08:29:02 PDT 2012
On Apr 16, 2012 3:22 PM, "Jouni Malinen" <j at w1.fi> wrote:
> 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/
> > 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
> > over a single PHY. I may be missing something here also. Please correct
> > understanding, if wrong. Apart from this doubt, everything else looks
> > with the cleaned up version of the patch.
> Well, that was the original assumption for driver_nl80211.c..
> Jouni Malinen PGP id EFC895FA
> HostAP mailing list
> HostAP at lists.shmoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap