[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 12/15] libxl: get and set soft affinity



On Mon, 2013-12-02 at 19:17 +0100, Dario Faggioli wrote:
> On mer, 2013-11-27 at 14:45 +0000, Ian Campbell wrote:
> 
> > > + */
> > > +#define LIBXL_HAVE_SOFT_AFFINITY 1
> > > +
> > > +/*
> > >   * LIBXL_HAVE_BUILDINFO_HVM_VENDOR_DEVICE indicates that the
> > >   * libxl_vendor_device field is present in the hvm sections of
> > >   * libxl_domain_build_info. This field tells libxl which
> > > @@ -994,9 +1002,35 @@ int libxl_userdata_retrieve(libxl_ctx *ctx, 
> > > uint32_t domid,
> > >  
> > >  int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
> > >  int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t 
> > > vcpuid,
> > > -                           libxl_bitmap *cpumap);
> > > +                           const libxl_bitmap *cpumap_hard,
> > > +                           const libxl_bitmap *cpumap_soft);
> > >  int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> > > -                               unsigned int max_vcpus, libxl_bitmap 
> > > *cpumap);
> > > +                               unsigned int max_vcpus,
> > > +                               const libxl_bitmap *cpumap_hard,
> > > +                               const libxl_bitmap *cpumap_soft);
> > > +
> > > +#if defined (LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040400
> > > +
> > > +static inline
> > > +int libxl_set_vcpuaffinity_0x040200(libxl_ctx *ctx, uint32_t domid,
> > > +                                    uint32_t vcpuid, libxl_bitmap 
> > > *cpumap)
> > > +{
> > > +    return libxl_set_vcpuaffinity(ctx, domid, vcpuid, cpumap, NULL);
> > > +}
> > > +
> > > +static inline
> > > +int libxl_set_vcpuaffinity_all_0x040200(libxl_ctx *ctx, uint32_t domid,
> > > +                                        unsigned int max_vcpus,
> > > +                                        libxl_bitmap *cpumap)
> > > +{
> > > +    return libxl_set_vcpuaffinity_all(ctx, domid, max_vcpus, cpumap, 
> > > NULL);
> > > +}
> > > +
> > > +#define libxl_set_vcpuaffinity libxl_set_vcpuaffinity_0x040200
> > > +#define libxl_set_vcpuaffinity_all libxl_set_vcpuaffinity_all_0x040200
> > 
> > This looks correct, thanks. It could also have jsut been #defined since
> > the inline is only used in the libxl_domain_create_restore_0x040200 case
> > because there is a local variable.
> >
> Yes, I saw that.
> 
> You mean something like this:
> 
> #define libxl_set_vcpuaffinity(_ctx, _domid, _vcpuid, _map) \
>     libxl_set_vcpuaffinity((_ctx), (_domid), (_vcpuid), (_map), NULL)
> 
> ?

Something like that yes.

> Well, I guess I can, but don't I more protection for the arguments /
> risk to clash with the app namespace, if I do?

Since the arguments of the inner function which are common to the outer
have the same types I don't think you gain any extra type checking and I
don't think the namespace clashes in practice (BTW, there is no need for
leading _ in macro arguments IIRC)

> That's the main reason why I used the inline variant, and that is true
> for v5 as well. If you prefer to go with the `#define' only, I can
> respin (either the series or the patch).

I don't have a strong preference, I was just observing in case you
thought it nicer.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.