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

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Ewan Mellor wrote:
> Xen-API Weekly Call, 12 June 2006, Minutes
> ==========================================
>   
[snip]
> 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
> approach.
>
> 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
>      compatibility.
>
>
> 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.
Jim

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api