On Wed, 2 Jul 2014 10:32:41 +0100
Will Deacon <will.dea...@arm.com> wrote:

> On Wed, Jul 02, 2014 at 10:17:20AM +0100, Cornelia Huck wrote:
> > On Tue,  1 Jul 2014 15:45:15 +0100
> > Will Deacon <will.dea...@arm.com> wrote:

> > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > > index e11d8f170a62..6875cc225dff 100644
> > > --- a/include/uapi/linux/kvm.h
> > > +++ b/include/uapi/linux/kvm.h
> > > @@ -940,15 +940,25 @@ struct kvm_device_attr {
> > >   __u64   addr;           /* userspace address of attr data */
> > >  };
> > > 
> > > -#define KVM_DEV_TYPE_FSL_MPIC_20 1
> > > -#define KVM_DEV_TYPE_FSL_MPIC_42 2
> > > -#define KVM_DEV_TYPE_XICS                3
> > > -#define KVM_DEV_TYPE_VFIO                4
> > >  #define  KVM_DEV_VFIO_GROUP                      1
> > >  #define   KVM_DEV_VFIO_GROUP_ADD                 1
> > >  #define   KVM_DEV_VFIO_GROUP_DEL                 2
> > > -#define KVM_DEV_TYPE_ARM_VGIC_V2 5
> > > -#define KVM_DEV_TYPE_FLIC                6
> > > +
> > > +enum kvm_device_type {
> > > + KVM_DEV_TYPE_FSL_MPIC_20        = 1,
> > > +#define KVM_DEV_TYPE_FSL_MPIC_20 KVM_DEV_TYPE_FSL_MPIC_20
> > > + KVM_DEV_TYPE_FSL_MPIC_42,
> > > +#define KVM_DEV_TYPE_FSL_MPIC_42 KVM_DEV_TYPE_FSL_MPIC_42
> > > + KVM_DEV_TYPE_XICS,
> > > +#define KVM_DEV_TYPE_XICS                KVM_DEV_TYPE_XICS
> > > + KVM_DEV_TYPE_VFIO,
> > > +#define KVM_DEV_TYPE_VFIO                KVM_DEV_TYPE_VFIO
> > > + KVM_DEV_TYPE_ARM_VGIC_V2,
> > > +#define KVM_DEV_TYPE_ARM_VGIC_V2 KVM_DEV_TYPE_ARM_VGIC_V2
> > > + KVM_DEV_TYPE_FLIC,
> > > +#define KVM_DEV_TYPE_FLIC                KVM_DEV_TYPE_FLIC
> > > + KVM_DEV_TYPE_MAX,
> > 
> > Do you want to add the individual values to the enum? A removal of a
> > type would be an API break (so we should be safe against renumbering),
> > but it's sometimes helpful if one can get the numeric value at a glance.
> 
> Could do, but then I think the advantage of the enum is questionable over
> the #defines, since you could just as easily have two entries in the enum
> with the same ID value as forgetting to update a KVM_DEV_TYPE_MAX #define
> (which was the reason for the enum in the first place).
> 
> So I'd be inclined to keep the patch as-is, unless you have really strong
> objections?

I don't really have a strong opinion on that, so

Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com>

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to