On 14 May 2014 10:25, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2014-05-14 at 07:14 +0200, Michal Kazior wrote: > >> Hmm.. I thought of it more as a theoretical appliance of the transaction API. >> >> Let me re-post his example: >> >> > With the generic transactions you could do: >> > - new chanctx2 >> > - new chanctx3 >> > - switch vif1 chanctx1->chanctx2 >> > - switch vif2 chanctx1->chanctx3 >> > - del chanctx1 >> >> From this I infer you can run at least 2 chanctx since that's what you >> end up with. This means you can perform one of the switches separately >> because only 1 chanctx was used (that's the easy part that never >> really required transactions or multi-vif-chanctx-assign to begin >> with). The other switch would fall into the "incompat case" where you >> need to basically swap chanctx for one of the vifs in the example. >> >> So I fail to see why we would need to have a list of old/new contexts >> in the proposed switch_vif_chanctx(), at least for now. > > Further down the thread there was a discussion about e.g. radar > detection with the combinations, when one needs radar and the other > doesn't or something, then maybe you're running into a situation where > some interface combination allows more than 2 channels and the other > doesn't, or such. Ah, you're right. I missed that. In that case we need to pass a list of old/new contexts to switch_vif_chanctx(). 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
