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

[Xen-devel] libxl stable API work left (Was: Re: [PATCH 00 of 27 v2] lib

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] libxl stable API work left (Was: Re: [PATCH 00 of 27 v2] libxl: rationalise libxl_device_* APIs)
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 13 Oct 2011 11:44:35 +0100
Delivery-date: Thu, 13 Oct 2011 03:53:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <patchbomb.1318499605@xxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <patchbomb.1318499605@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-10-13 at 10:53 +0100, Ian Campbell wrote:
> Along the way I filed some rough edges of the internal implementation
> of this stuff but my primary concern is to make the public facing API
> one that we can commit to keeping stable.

Speaking of which, my laundry list for things which need to happen to
libxl's API to make it stable contains:
      * The stuff this series addresses
      * Fixup the event API (IanJ)
      * Block script support (IanJ?)
      * The topologyinfo datastructure should be a list of tuples, not a
        tuple of lists.

I've also got:
        I've also been wondering what can/should be done about the split
        between libxl_domain_create_info, libxl_domain_build_info and
        libxl_device_model_info now that they are all bundled together
        in libxl_domain_config and not exposed directly in the API
        (since the related functions became internal, that was before
        4.1). It seems like there ought to be scope for collapsing those
        datastructures somewhat but I'm not sure how yet.
        
But I think this conflicts with the need to do certain bits
asynchronously (primarily for script calling support on create) which I
expect will necessitate splitting libxl_domain_create up again.

If you are (or are going to be) a consumer of the libxl API you would be
well advised to have a read through libxl.h and make sure you are happy
with the rest of it.

Ian.


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