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? 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? 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
