WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] future plans for libxl?

To: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] future plans for libxl?
From: Andre Przywara <andre.przywara@xxxxxxx>
Date: Thu, 15 Apr 2010 10:22:48 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 15 Apr 2010 01:25:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BC6C374.7030907@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4BC578DF.9000508@xxxxxxx> <alpine.DEB.2.00.1004141637250.7041@kaball-desktop> <4BC6BE62.3020000@xxxxxxx> <4BC6C374.7030907@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090329)
Vincent Hanquez wrote:
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.
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.

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?

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.
QEMU implements something in it's migration interface to support different version of the emulated devices. It's easier there though because they read each member explicitly from the stream and don't need to fiddle around with mapping structs.

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.
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? 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.

Regards,
Andre.

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel