On Fri, Jun 16, 2017 at 05:36:18PM +0800, Zhongze Liu wrote: > 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.
Both are used. We should use domid_t for new code. > > >> + 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? > I agree with what Jan said. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel