On 7 May 2014 13:54, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2014-05-07 at 13:19 +0200, Michal Kazior wrote: >> On 7 May 2014 13:09, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: >> > On Wed, 2014-05-07 at 12:38 +0200, Michal Kazior wrote: >> > >> >> I was actually thinking of just providing the bare minimum to fulfill >> >> requirements for the CSA case: int foo(*hw, **vifs, n_vifs, *oldctx, >> >> *newctx, flags). >> >> >> >> Having an array of transactions passed through a single call seems >> >> more robust and cleaner. Naiive drivers might just iterate over each >> >> entry while more complex drivers might examine the whole request and >> >> detect chanctx swapping. >> > >> > Not sure what you mean by "detect chanctx swapping" - the flags would >> > indicate that anyway, no? In any case, I like this better than a more >> > general transaction API I think, it's easier for the driver >> > implementation and clearer as to what needs to be done/supported. >> >> You could submit a transaction sequence: >> - new chanctx2 >> - switch vif1 chanctx1->chanctx2 >> - switch vif2 chanctx1->chanctx2 >> - remove chanctx1 > > Well, you don't really have any other choice with the API you proposed, > and IMHO that's a good thing. The only possibilities that can be > expressed with that would seem to be: > > 1) for_each_vif: switch vif from oldctx to newctx > 2) add newctx > for_each_vif: switch vif from oldctx to newctx > del oldctx > > With the option between 1/2 being selected by the flags. I don't see > what the driver has to infer about it being a channel switch - it > necessarily is one, no? Yeah - existing usecases include only CSA and some primitive ops. What I mean is if you want to avoid chanctx overcommit you need to perform (2) the other way around (i.e. first unassign and delete oldctx and then create newctx), at least internally. This would simply be more of a hassle with multiple call transaction API. 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
