Re: [Xen-devel] [PATCH 1/2] rename XENMEM_add_to_physmap_{range => batch} (v2)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-01-07 at 12:31 +0000, Jan Beulich wrote:
> >>> On 07.01.14 at 13:24, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2013-12-20 at 13:07 +0000, Jan Beulich wrote:
> >> The use of "range" here wasn't really correct - there are no ranges
> >> involved. As the comment in the public header already correctly said,
> >> all this is about is batching of XENMEM_add_to_physmap calls (with
> >> the addition of having a way to specify a foreign domain for
> >> XENMAPSPACE_gmfn_foreign).
> >> 
> >> Suggested-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > 
> > Were you targeting this one at 4.4?
> 
> Yes, so that the old form of it doesn't go into wide spread use.
> Also implied by ...
> 
> >> +#if __XEN_INTERFACE_VERSION__ < 0x00040400
> >> +#define XENMEM_add_to_physmap_range XENMEM_add_to_physmap_batch
> >> +#define xen_add_to_physmap_range xen_add_to_physmap_batch
> >> +typedef struct xen_add_to_physmap_batch xen_add_to_physmap_range_t;
> >> +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> >> +#endif
> 
> ... the conditional here.

Yes, that's what I inferred.

So if you need a release Ack then I think you can have one from me in
George's absence. The risk is basically build breakage which should be
trivially caught and the benefit is not exposing a broken API in the new
release.

Ian.


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