[Xen-API] Re: Xen-API C Bindings, version 0.4.1

["Mike D. Day" <ncmike@xxxxxxxxxx>]

On 08/08/06 17:00 +0100, Ewan Mellor wrote:

> Attached is the latest version of the C bindings for the Xen Management API.
>
> A record that contains references to other records (Ref in the data model) has
> fields of record_opt type.  This type is a tagged union -- either a handle
> referring to the object, or a full copy of the object's fields.  The
> get_record calls are only shallow -- they return handles as those references,
> not full copies -- but I anticipate that we shall add some deep calls later.



> I've added constructors, such as xen_vm_create, that take a xen_vm_record, and
> use that to supply parameters to the construction.
>
> All items that are allocated by the library and passed to the user have a
> corresponding call for deallocation (xen_vm_free, for example).
Simple style question: should we typedef structs? I like the shorthand
but linux style has some advantages. typedefs tend to hide information
about the type that can be important. 

I like the internal structure of the API. It might be nice for each
type/value to have pluggable marshall/demarshall functions. The
marshall/demarshall code in xen_common.c is great but usually there
are cases where a user needs to roll his own.

Memory management: 

Right now the user supplies a buffer with input values (which is
copied by the API), and the API supplies a result buffer, which the
user needs to free. This is always hard to get right. It might make
sense for the caller to provide both. This would avoid a memcpy and
would reduce memory consumption. Since the caller is also part of the
API implementation I think it would be best to avoid the memcpy.

The current prototype should make params const:

void
xen_call_(xen_session *s, const char *method_name,
-         abstract_value params[], int param_count,
+         const abstract_value params[], int param_count,
         const abstract_type *result_type, void *value)


But I would rather prefer this, with the caller supplying parameter
memory:

void
xen_call_(xen_session *s, const char *method_name,
-         abstract_value params[], int param_count,
+         const abstract_value *params[], int param_count,
         const abstract_type *result_type, void *value)


#define XEN_CALL_(method_name__)                                \
   xen_call_(session, method_name__, param_values,             \
             sizeof(param_values) / sizeof(param_values[0]),   \
             &result_type, &result)                            \

The XEN_CALL macro is kind of scary because it uses inferred
variables. It's probably because I'm not used to this convention but I
would prefer 

#define XEN_CALL_ xen_call_ 

In other words, it really isn't needed and we should just expand the
macro ourselves becuase.


More later, nice work!

Mike

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