From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 06 of 11] libxl: introduce libxl_get_numainfo() Date: Fri, 1 Jun 2012 17:44:31 +0100 Message-ID: <4FC8F16F.30405@eu.citrix.com> References: <5c4b4f0c184fa3534bcb.1338466271@Solace> <20423.32435.342657.764548@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20423.32435.342657.764548@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , "xen-devel@lists.xen.org" , Dario Faggioli List-Id: xen-devel@lists.xenproject.org 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