[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 06 of 11] libxl: introduce libxl_get_numainfo()



On 31/05/12 15:22, Ian Jackson wrote:
Dario Faggioli writes ("[PATCH 06 of 11] libxl: introduce 
libxl_get_numainfo()"):
Make some NUMA node information available to the toolstack. Achieve
this by means of xc_numainfo(), which exposes memory size and amount
of free memory of each node, as well as the relative distances of
each node to all the others.
...
+#define LIBXL_NUMAINFO_INVALID_ENTRY (~(uint32_t)0)
Is there some reason we can't just make sure we use the same value for
this in both places ?  That would avoid the need for this:

+#define V(mem, i) (mem[i] == INVALID_NUMAINFO_ID) ? \
+    LIBXL_NUMAINFO_INVALID_ENTRY : mem[i]
I appreciate that the types aren't the same.  In libxc it's an
unsigned long.  But shouldn't they be the same ?
It looks like Dario was just following suit from the topology interface:

xen/include/syctl.h: #define INVALID_TOPOLOGY_ID  (~0U)
tools/libxl/libxl.h: #define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)

It might be worth seeing who wrote those and asking that person why they thought it was important. It might be something to do with making the libxl type a fixed size...?
In libxl you can use libxl__zalloc(NULL,...) (and don't have to check for errors because it can't fail). But perhaps this is going into libxc ? I'd like to hear what other people say about putting this in libxl vs. libxc.
I dunno, whom do we expect to be calling libxc? If the answer is "One day, only libxl", then it's just a matter of taste. Otherwise, we need to ask whether someone might want to call such a function w/o having to link to libxl.

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.