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/
Home Products Support Community News


Re: [Xen-API] Xen-API Weekly Call, 12 June 2006, Minutes

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Xen-API Weekly Call, 12 June 2006, Minutes
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Thu, 13 Jul 2006 17:06:43 -0600
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 13 Jul 2006 16:07:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060713124250.GB27183@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <20060713124250.GB27183@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060516)
Ewan Mellor wrote:
Xen-API Weekly Call, 12 June 2006, Minutes
C Bindings

The C bindings were posted to the Xen-API mailing list a couple of hours
before the call.  With such a short lead time, of course most people had not
had time to absorb the proposal, so a short time was spent talking through the

A number of changes were proposed, mainly by Daniel Veillard, and these will
be folded into the next version of the proposal.  The changes are:

  o  Add a call to explicitly free each of the object handles (xen_vm in the
     given example), rather than stating that the caller should free it.  This
     allows the binding to decide how to allocate these handles.                
                        ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
o Add a call such that a struct can be populated in one go, rather than
     requiring a number of calls to read each field in turn from the server.

  o  Add the ability to get a UUID as a packed 16 byte value rather than the
     readable form used at the moment, for compatibility with libvirt.

  o  Add a version number to the interface.

  o  Add padding to all structures, to make it easier to preserve ABI

There was much discussion of xen_vm_create, and how parameters should be
passed in to these calls.  Ewan made it clear that the example shows only a
few fields, and that it was intended in the example that all fields marked
ROins and RW in the API document would be passed into the xen_vm_create call,
each as a a separate parameter.

It was proposed instead that a structure could be passed into this call (the
same as the struct that will populated by the call mentioned above), rather
than having to give each field individually.  Alternatively, an XML fragment
could be passed in, and that used to populate the new object instead.  Daniel
said that libvirt used to use an XML fragment, but that it was changed to use
a struct, because libvirt's users did not want to manipulate XML themselves.

The binding can't decide how to allocate the structs if at the same time the client is filling them out on create. Perhaps we should do a create in steps, passing params at each step and getting back a structure allocated by the binding for use in the next step. E.g. xen_vbd_create(some, params), xen_vif_create(some, params), etc. whose return values will be used in xen_vm_create(). The API should be symmetric wrt memory allocation, not client handles memory of structs for some calls but binding handles it for others.

BTW, libvirt currently does use an XML string for config on create. I mentioned that it would be nice to use structs so client would not be burdened with parsing / creating XML. It has not been done in libvirt yet due to lack of standard interface :-).

There was discussion of the way that Sets are handled in the interface.
Daniel said that he did not like the fact that Sets are returned as a
malloc()d array by the API, with the caller expected to free() that array
later.  He would rather that the caller could allocate space for the array,
and then pass this space into the API in order to be filled.  This would allow
the caller to allocate memory in any way they chose, including on the stack.

Ewan pointed out that this leaves you with a race condition, whereby you make
a call to find out how big the array has to be, but then this subsequently
changes, causing you to have to retry.

A solution that all are happy with was not found.

If we go with "binding decides how to allocate handles" concept above, why not here as well? But if caller provides memory, maybe the function can take a 'hasMore' parameter that would be set if caller-provided buffer was insufficient to contain all set members.


xen-api mailing list

<Prev in Thread] Current Thread [Next in Thread>