[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |