On Wed, 2012-05-09 at 11:41 +0200, Michal Kazior wrote: > Johannes Berg wrote: > > I don't think this patch is correct -- mac80211 will get updated even if > > the device isn't even started which will likely cause trouble. Even if > > not though, this all doesn't match any kind of multi-channel concept. We > > treat the channel as part of the temporary setup, e.g. part of the > > association. AP and mesh are the only ones that are different today I > > think. > > What about monitor mode? It's ... special and confusing, unfortunately. Basically, it's handled in mac80211 today, it rejects monitor channel setting unless it's otherwise idle, and overrides it freely if other requests come in. > > We should do the same for AP mode as well, since the channel really > > becomes relevant only upon start_ap(), before that there's no real > > concept of a channel since you don't use it yet anyway. > > Maybe we should do the same with monitor interface type, i.e. introduce > start_monitor() and have it pass the channel. No, that's the special case that doesn't work that way -- monitor mode interfaces are also great for debugging when they're just concurrently running with other interfaces and don't have their own channel setting. > But then I'm thinking we shouldn't really be changing interface types > explicitly, since they would be set implicitly by start_ap() and such. > We could then use the NL80211_IFTYPE_UNSPECIFIED when we're not associated. >From some point of view, it should work that way, yes. Given how entrenched interface types are we definitely can't get rid of them though, and they're still needed to do concurrency management etc. But changing everything to have explicit start/stop operations makes on-the-fly interface type changes much easier. johannes -- 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
