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
|
Home