Re: [PATCH v5] mac80211: implement multi-vif in-place reservations

[Luca Coelho <luca@coelho.fi>]

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.