On Tue, Nov 16, 2010 at 09:03:15AM -0800, Ben Greear wrote: > It would be easy enough to save the phyname in the wpa_s struct so it > doesn't need to be probed all the time. phyname sounds like a Linux/mac80211/cfg80211 specific thing and probably does not belong in wpa_s.. But yes, some kind of identifier for interfaces sharing the same radio there or in the private driver wrapper data would be fine (if it within driver_nl80211.c, phyname would be perfectly valid thing to store at initialization). > As for the logic that actually propagates scan results to all of the > peer VIFS, do you mean you want that moved farther up into the driver > as well? I think I would be fine with either option as a starting point, i.e., driver_nl80211.c can maintain an internal list of interfaces and propagate the scan complete event to each interface or there can be an abstract radio identifier exposed by the driver wrapper to allow core supplicant code to handle this. I'm assuming here that it is possible to read the scan results from any vif in mac80211 regardless of which generated the scan-completed event. Is that correct? > It simple to know the phy-name for a particular VIF (on the latest kernel), > so knowing parent-child and sibling relationships is also easy. Older > kernels don't have the phy-name available in sysfs, but they also didn't > support multiple VIFS well anyway..so maybe just ignore them? Yeah, I have no problems in ignoring old versions for this kind of new functionality. > I was afraid that one VIF might scan with one set of scan-options and another > a different set. However, I have no real understanding of how wpa_supplicant > works, so if you think it can be always enabled, then I'm fine with that. That can already happen even with a single vif when other applications are requesting scans.. wpa_supplicant will have to handle it cleanly anyway. > Also, with it enabled, I can currently reliably crash ath9k. This is a > kernel bug that hopefully can be fixed soon, but it would be one small reason to > keep the old behaviour available. What exactly is the trigger for the crash? Multiple vifs? Or this type of optimization for re-using scan results? Anyway, I don't think we should care about that in the context of designing what should be added into wpa_supplicant. If a kernel driver is buggy, it will be fixed, or you better not try to use this feature ;-). -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
