[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:

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

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!


xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.