On 15 January 2014 10:39, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2014-01-15 at 07:52 +0100, Michal Kazior wrote: > >> So you're basically saying the new attribute should be used as an >> array attribute instead. Sounds good, but.. >> >> What about backward compatibility? Do we not care? Or should we >> preserve old parsing for single-interface CSA (i.e. older hostapd)? > > I think we have to preserve the old parsing if the new isn't present, > but that shouldn't be all that difficult? > > if (info->attrs[MULTI]) > for_each_attr(a, info->attrs[MULTI]) > parse_nested(a, attrs); > parse(attrs); > else > parse(info->attrs); > > or something like that, right? Agreed. >> > is more error prone as it would allow older kernels to parse the whole >> > thing while ignoring the next/more/whatever, so you'd get some weird >> > subset of the intended behaviour. Forcing *all* interfaces into the >> > sub-attribute when more than one is desired (or in fact for a single >> > one, if you're ok with requiring a kernel with support) would IMHO be >> > less error prone. >> >> From a practical point of view cfg80211 should deny such a request due >> to multi-channel (interface combination) and by (the only CSA >> implementator in upstream) mac80211 due to chanctx->refcount > 1. > > Hmm, true. I'd still prefer the other version, the stacked/nested one > kinda makes me uncomfortable ... It'll work, no doubt about it, but the > deep nesting I'm not really happy with. I'll work on that then. Michał -- 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
