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

Re: [Xen-devel] [PATCH 3/4] move XENMEM_add_to_physmap_range handling framework to common code



On Fri, 2013-12-20 at 07:58 +0000, Jan Beulich wrote:
> >>> On 19.12.13 at 11:48, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > Personally I think that having two redundant ways of doing the same
> > thing is the more pointless of the two. Especially given the need to
> > think a bit carefully about what XENMEM_add_to_physmap_range
> > XENMAPSPACE_gmfn_range might mean...
> 
> Yes, that combination is bogus whichever perspective you take.
> To some degree also because "range" in the former name is really
> wrong - the operation doesn't deal with a range, but with a group
> (batch) of individual pages.

That's true. I suppose there would be no harm in 
#define XENMEM_add_to_physmap_batch 23
#if __XEN_INTERFACE_VERSION__ < xxx
#define XENMEM_add_to_physmap_range XENMEM_add_to_physmap_batch.
#endif

> However, I meanwhile realized that from an interface perspective
> (I'm not proposing to implement this right now!) the combination
> could actually be made work - the errs array (being an output only
> at present) could be re-used to serve as input to pass the sizes.
> The main issue of implementing this would be how to deal with the
> two necessary layers of preemption.

That's pretty cunning!

> So I'm going to re-add the check.

Given the above I'm doubly in favour of doing so.

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®.