On 13 May 2014 17:53, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2014-05-13 at 15:56 +0200, Michal Kazior wrote: > >> > That's pretty much what I'd considered, except that now as far as I read >> > the thread this wasn't sufficient for multi-context, so we'd need lists >> > of old/new contexts? >> >> Hmm.. In what cases do you need a list of old/new contexts? > > That was Luca's scenario, no? 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. 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
