From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: future plans for libxl? Date: Thu, 15 Apr 2010 08:42:44 +0100 Message-ID: <4BC6C374.7030907@eu.citrix.com> References: <4BC578DF.9000508@amd.com> <4BC6BE62.3020000@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: <4BC6BE62.3020000@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 08:21, Andre Przywara wrote: > I stumbled upon missing 'info' support, so I implemented a basic version > of it. A few questions about it: > 1.) Is there a fixed interface for libxenlight? I see libxc interfaces > duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a > more stable interface than xc does (which changed quite a bit lastly). > What about extending this interface? For complete xl info I need more > field of the physinfo sysctl to be provided by libxl_get_physinfo, is it > OK to extend the struct libxl_physinfo? yes, i've duplicated them for this exact purpose. it could work hand-in-hand with what i'm describing below. for extending usually, you would just add a new field at the end of the structure. it's probably ok to extends the physinfo structure. however we tried to separate some things that would be not very useful from a toolstack point of view, compared to actually carrying all sorts of info of questionable usefulness. > 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init(). > Is that meant to be that hard or is a compatibility scheme planned > (like: support apps using on older interface and somehow emulate it?) it takes lots of resources to do a compat scheme. but eventually it could all be done with the LIBXL_VERSION check. if you upgrade the library and something change, the previously compiled client would still use a LIBXL_VERSION < compared to the current one in the library. at this point, libxl could provide a mechanism to provide old -> new structure mechanism to provide automatic compatibilty with old userspace. note that it wouldn't cover function prototype change, but only structure change, and this is an extremly painful process where you need to keep your old structure around, and have a (potentially) big fast switch case in function that need this compat layer. it's much much simpler to just let client and library to be the exact same version, which is what the ctx_init function is doing at this point compared to the elaborate scheme of compat. -- Vincent