Re: [PATCH 6/8] virDriverFeatureIsGlobal: Handle VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER

On 2/16/22 16:41, Peter Krempa wrote: > The fix was on RPC level so everything should advertise it. > > Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; > --- > src/driver.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/driver.c b/src/driver.c > index d070861cfd..54b4ad5b43 100644 > --- a/src/driver.c > +++ b/src/driver.c > @@ -357,10 +357,12 @@ virDriverFeatureIsGlobal(virDrvFeature feat, > * At this point everything supports them and thus also drivers need to > * always advertise this feature */ > case VIR_DRV_FEATURE_TYPED_PARAM_STRING: > + /* Feature flag exposes that accidental switching of order of arguments > + * in RPC was fixed. All implementations need to advertise this feature */ > + case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: > *supported = 1; > return true; > > - case VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER: > case VIR_DRV_FEATURE_FD_PASSING: > case VIR_DRV_FEATURE_MIGRATION_V2: > case VIR_DRV_FEATURE_MIGRATION_V3: Just FYI, RPC layer doesn't have to necessary be involved. We have embed mode which uses drivers directly. Even though, network driver is currently doesn't work in embed mode. And strictly speaking this was not tied to RPC, the problem was in public API implementation which called the callback with swapped arguments. So any of local drivers (remote driver, ESX, test driver, ...) were affected too, even though it's the remote driver alone that implemented the callback.

I'm not objecting to this patch, just trying to shed more light into the problem.