[libvirt] [PATCH] util: fix build without macvtap

[Michal Privoznik]

On 27.01.2016 03:45, Roman Bogorodskiy wrote:
> Commit 370608b added new functions:
> 
>  - virNetDevMacVLanReleaseName,
>  - virNetDevMacVLanReserveName.
> 
> Add stubbed versions of them to fix build without macvtap.
> ---
>  src/util/virnetdevmacvlan.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
> index da71eef..9293510 100644
> --- a/src/util/virnetdevmacvlan.c
> +++ b/src/util/virnetdevmacvlan.c
> @@ -1330,4 +1330,21 @@ int virNetDevMacVLanVPortProfileRegisterCallback(const char *ifname ATTRIBUTE_UN
>                           _("Cannot create macvlan devices on this platform"));
>      return -1;
>  }
> +
> +int
> +virNetDevMacVLanReserveName(const char *name ATTRIBUTE_UNUSED,
> +                            bool quietFail ATTRIBUTE_UNUSED)
> +{
> +    virReportSystemError(ENOSYS, "%s",
> +                         _("The macvlan devices are not supported on this platform"));
> +    return -1;
> +}
> +
> +int
> +virNetDevMacVLanReleaseName(const char *name ATTRIBUTE_UNUSED)
> +{
> +    virReportSystemError(ENOSYS, "%s",
> +                         _("The macvlan devices are not supported on this platform"));
> +    return -1;
> +}
>  #endif /* ! WITH_MACVTAP */
> 

Oh, sorry. I started working on the same patch as soon as I got to the
office and haven't checked for the e-mails just to find out that you
already have a patch for that.

Next time you may as well just push the patch. There are basically two
rules under which a patch can be pushed without review:

1) Trivial - patch is just trivial (e.g. fixing an indentation, or a
typo and stuff like that). Although, several trivial changes when
combined create a non-trivial patch. So it's okay to push if commit is
fixing few whitespaces, but fixing spelling from british to american in
whole codebase will require proper review.

2) Build breaker - if the fix is obvious and moreover it fixes a broken
build, you may just push the patch. This situation is a good example of
such case. Although the fix is trivial too.

Anyway, in both cases you must send the patch you've pushed to the list
and note in comments that it's already pushed. The reason for that is so
that upstream can check if the fix was good and if somebody has a better
idea they can propose it.

Once again, sorry for taking over credit from you.

Michal