[PATCH 6/8] virDriverFeatureIsGlobal: Handle VIR_DRV_FEATURE_NETWORK_UPDATE_HAS_CORRECT_ORDER

[Michal Prívozník]

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 at redhat.com>
> ---
>  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.

Michal