From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: future plans for libxl? Date: Thu, 15 Apr 2010 10:35:13 +0100 Message-ID: <4BC6DDD1.5030608@eu.citrix.com> References: <4BC578DF.9000508@amd.com> <4BC6BE62.3020000@amd.com> <4BC6C374.7030907@eu.citrix.com> <4BC6CCD8.9080509@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4BC6CCD8.9080509@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andre Przywara Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 15/04/10 09:22, Andre Przywara wrote: > OK, what is missing currently is nr_nodes, {hw,virt}_caps and the whole > bunch of (currently in flux) NUMA information. I think the whole NUMA > info should be moved into either a topology or a NUMA structure > (together with libxl_get_... functions). But I'd like to see at least > nr_nodes and the caps within the physinfo structure. One can debate > about the nr_nodes fields, though. Not sure about numa, it seems to be in flux in xen-unstable at the moment, so i'ld rather leave this interface alone, until it's sorted. For the caps things, you might want to consider something a bit more high level than passing a bitfields through. For example you could actually transform the caps bitfields into an array of decoded values. that's a bit more friendly to use from a user of libxl PoV. > What about xc_version(), by the way? This provides a lot of information > currently shown in xm info, I didn't found any interface for that in > libxenlight. Is it OK to implement it? Or shall I call xc_version() > directly from xl.c? i think it would be nice to have a easy user interface that do a bunch of xc_version calls and put them in a structure ready to be processed. > I agree that the whole effort is probably not worth the gains. > Especially since we have only one library one could update this together > with the tools. If we came to some kind of stable interface, one could > use the standard UNIX library versioning scheme. > The only question is if we can keep pace with the hypervisor > development. If it introduces new features, hypercalls, extended > structures do we really want to break compatibility or do we refrain > from implementing new features? my take on it is, new features are more important than compat. if it happens that we *have* to break an interface to implement a new feature, then it should be done; although probably trying to minimize the disruption is probably a good idea. > I suppose that at least in the -unstable tree we don't care about > compatibility and only keep a stable interface in the -testing trees, > the libxl version could then be named after the stable hypervisor version. hmm. I think even in unstable, we would try to keep compat as possible. not sure what the policy with testing is going to be. -- Vincent