Hi Jan,
2017-06-16 16:45 GMT+08:00 Jan Beulich <jbeul...@suse.com>: >>>> On 16.06.17 at 06:55, <blacksk...@gmail.com> wrote: >> currently there is no wrapper for XENMEM_add_to_physmap_batch in libxc. >> add a wrapper to do that. > > It may help acceptance if you say why all of the sudden a wrapper > is needed. > It's indeed a preparation for my GSoC project: https://lists.xen.org/archives/html/xen-devel/2017-05/msg01288.html Thanks for the suggestion. > >> --- a/tools/libxc/include/xenctrl.h >> +++ b/tools/libxc/include/xenctrl.h >> @@ -1372,6 +1372,15 @@ int xc_domain_add_to_physmap(xc_interface *xch, >> unsigned long idx, >> xen_pfn_t gpfn); >> >> +int xc_domain_add_to_physmap_batch(xc_interface *xch, >> + uint32_t domid, >> + uint32_t foreign_domid, > > I'm not exactly sure what the libxc coding rules are, but I'd expect > these both to be domid_t, ... > I was planning to make them domid_t, but according to the other domid-parameters' types in the file, and they are all uint32_t, so I finally decided on uint32_t. >> + unsigned int space, >> + uint16_t size, > > ... this one to be unsigned int, ... In the xen_add_to_physmap_batch struct, both @space and @size are uint16_t, so I think I should have made @space uint16_t, too. I'll fix this. Or do you have any good reasons to make both of them unsigned int? > >> + xen_ulong_t *idxs, >> + xen_pfn_t *gfpns, > > ... and these two to be pointers to const. > Yes, indeed. Sorry for this. > > Jan > Cheers, Zhongze Liu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel