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

[George Dunlap <george.dunlap@eu.citrix.com>]

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