[libvirt] [PATCH 3/6] pci: Introduce virPCIStubDriver enumeration

[Michal Privoznik]

On 17.12.2015 16:23, Andrea Bolognani wrote:
> This replaces the virPCIKnownStubs string array that was used
> internally for stub driver validation.
> 
> Advantages:
> 
>   * possible values are well-defined
>   * typos in driver names will be detected at compile time
>   * avoids having several copies of the same string around
>   * no error checking required when setting / getting value
> 
> The names used mirror those in the
> virDomainHostdevSubsysPCIBackendType enumeration.


> diff --git a/src/util/virpci.h b/src/util/virpci.h
> index e628ab8..506a68c 100644
> --- a/src/util/virpci.h
> +++ b/src/util/virpci.h
> @@ -43,6 +43,15 @@ struct _virPCIDeviceAddress {
>  };
>  
>  typedef enum {
> +    VIR_PCI_STUB_DRIVER_XEN = 0,
> +    VIR_PCI_STUB_DRIVER_KVM,
> +    VIR_PCI_STUB_DRIVER_VFIO,
> +    VIR_PCI_STUB_DRIVER_LAST
> +} virPCIStubDriver;

Is there any specific reason to explicitly set _XEN = 0? I mean, by
default any new PCI device that we create in memory (virPCIDeviceNew())
will have _XEN as stub driver until set by virPCIDeviceSetStubDriver().
I'm not saying it's wrong, just asking.

For instance, if we reserve zero for a special case when stub driver
hasn't been set, we can throw an error and detect a bug in our code.

> +
> +VIR_ENUM_DECL(virPCIStubDriver);
> +
> +typedef enum {
>      VIR_PCIE_LINK_SPEED_NA = 0,
>      VIR_PCIE_LINK_SPEED_25,
>      VIR_PCIE_LINK_SPEED_5,

Michal