On Wed, 2014-05-07 at 15:06 +0200, Johannes Berg wrote: > On Wed, 2014-05-07 at 15:53 +0300, Luca Coelho wrote: > > > > > > new chanctx3 > > > > > switch vif2 chanctx1->chanctx3 > > > > > switch_transaction(chanctx1, chanctx2, vif1) > > > > > > > > Couldn't this potentially break the combinations temporarily again? > > > > > > I don't see why? You had a spare channel context to start with, > > > otherwise you'd never have accepted this situation. Therefore, you can > > > use the spare one before actually doing the proposed > > > switch_vif_chanctx(). > > > > It's not about the spare, it's about having this temporarily: > > > > chanctx3-vif2 > > chanctx1-vif1 > > > > Can we be sure that chanctx1 with vif1 is compatible with chanctx3 with > > vif2? We only check chanctx2 with vif1 and chanctx3 with vif2, which is > > our final goal. > > > > I'm not sure this is even possible, but it was something like this I had > > in mind. > > Oh, I get it, you're thinking that there might be a situation where > those vif types are maybe not supported with different channels? > > But in your example you're going from this situation: > > chanctx1: vif1, vif2 > > to > > chanctx2: vif1 > chanctx3: vif2 > > > The intermediate step that I proposed would give you > > chanctx1: vif1 > chanctx3: vif2 > > Which isn't really any different? It could be different if the channel in chanctx1 requires radar and chanctx2 doesn't, couldn't it? > Maybe you could construct a more > difficult via situation though where it actually does end up with a > conflict - or can we prove that can't happen? I can't come up with good examples, but yeah, proving it *can't* happen would be good. :) -- Luca. -- 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
