On Wed, 2010-09-15 at 12:28 +0100, Juergen Gross wrote:
> On 09/15/10 12:22, Ian Campbell wrote:
> > On Wed, 2010-09-15 at 10:37 +0100, Ian Campbell wrote:
> >> On Wed, 2010-09-15 at 10:23 +0100, Juergen Gross wrote:
> >>>
> >>> And I'm not sure I'll get the generating of the bindings correctly.
> >>> So yes, please do it!
> >>
> >> Will do.
> >>
> >> > From looking at your patch it seems that the intention is that the size
> >> is the number of bytes in the map, rather than the number of CPUs which
> >> can be represented or the number of uint64_t's, is that right and/or
> >> what you would like to use?
> >
> > Seems like libxc counts bytes but libxl (with your patch) counts 64 bit
> > words.
> >
> > There doesn't seem to be any users of the size currently so I went with
> > bytes in the below (compile tested + examined generated code only) but
> > since your patch adds the first actual user feel free to change it if
> > that makes the libxl interface more suitable for your needs or whatever.
>
> Thanks, updated patch is attached.
> I didn't add the destructor, because this would have made things much more
> complicated as libxl_list_pool returns an array of libxl_poolinfo elements.
> Doing only one free() at caller side is much easier than cycling through
> the elements and free-ing all extra allocated cpumaps.
I'm afraid I think you do need to cycle through the elements calling
libxl_poolinfo_destroy on each, this is consistent with how all other
libxl types are handled and means that users of the library are isolated
from a certain amount of change to the underlying types.
Often you can destroy each element as you walk over the list doing
whatever it is you needed the list for, for example see how
xl_cmdimpl.c:print_domain_vcpuinfo does it. libxl_list_vcpu has
basically the same semantics as libxl_list_pool should have.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home