|
xen-api
Re: [Xen-API] Xen-API Weekly Call, 12 June 2006, Minutes
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
|
|
|
Home