Re: [Xen-devel] [PATCH 01 of 11 v3] xen, libxc: rename xenctl_cpumap to xenctl_bitmap

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-03-12 at 17:06 +0000, Dario Faggioli wrote:
> On mar, 2013-03-12 at 15:46 +0000, Ian Campbell wrote:
> > On Fri, 2013-02-01 at 11:01 +0000, Dario Faggioli wrote:
> > > This is in preparation of introducing NUMA node-affinity maps.
> > 
> > The second patch doesn't use this new infrastrucuture though, and has
> > "typedef uint8_t *xc_nodemap_t" instead. 
> >
> Indeed, exactly as it happens for xc_cpumap_t, independently from both
> the first and the second patch of this series. However, the second patch
> defines xenctl_bitmap_to_nodemask() and nodemask_to_xenctl_bitmap(),
> which is what uses xenctl_bitmap.
> 
> Fact is xenctl_bitmap is used within DOMCTLs, while xc_{cpu,node}map_t
> is used by xc_*_{set,get}_affinity(), which is what, for instance, libxl
> calls.

so xenctl_bitmap is completely internal to the library/hypervisor and
the user of libxc doesn't see it?

> The split and the ordering of the series is meant at allowing patch 2 to
> define everything that is nodemap related, inside libxc, including the
> xenctl_bitmap_to_nodemask() (and reverse) functions above. Actual usage
> of both the types and related interfaces, only happen in subsequent
> patches.
> 
> > Which makes sense since a
> > node-affinity map is not a bitmap, is it?
> > 
> They all are the same thing, but represented differently depending on
> where we are.
> 
> All that being said... Did I answer? :-)
> 
> > > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > > --- a/xen/include/public/xen.h
> > > +++ b/xen/include/public/xen.h
> > > @@ -851,9 +851,9 @@ typedef uint8_t xen_domain_handle_t[16];
> > >  #endif
> > > 
> > >  #ifndef __ASSEMBLY__
> > > -struct xenctl_cpumap {
> > > +struct xenctl_bitmap {
> > >      XEN_GUEST_HANDLE_64(uint8) bitmap;
> > > -    uint32_t nr_cpus;
> > > +    uint32_t nr_elems;
> > 
> > Is this really "nr_bits" or can an entry in the bitmap be > 1 bit?
> > 
> I'm not sure I understand what you meant to say here, I'm afraid. The
> field encodes the number of elements the bitmap has to accommodate and
> deal with. In the (original) xenctl_cpumap case, that was the number of
> CPUs... All I'm doing is generalizing that from CPUs to some unspecified
> "element". It never was the size of the bitmap in bits, and is not
> becoming anything like that after the change.

Ah, so it is the number of bytes allocated in the bitmap field?

nr_elems is confusing because the elements of this particular array are
(logically at least) bits, yet nr_elems contains bytes. Why not call it
nr_bytes if that is what it contains?

> 
> But again, I did not get the question, so I'm probably not answering
> either... :-(
> 
> Thanks and Regards,
> Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel