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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

Wow, that's an incredible amount of code written already ! I managed to
compile & run the test programs without any significant trouble. The only
two very minor issues I had were likely just related to differing versions
of the dependant libraries from our respective OS platforms:

1. The Makefile sets -Werror but the xen_common.c spews a tonne of warning
   messages resulting in a failed compile (I removed the -Werror to complete
   the compile). FYI the warnings were all along the lines of:

cc -Iinclude -I/usr/include/libxml2  -W -Wall -Wextra -std=c99 -O2 -fPIC   -c 
-o src/xen_common.o src/xen_common.c
src/xen_common.c: In function ?xen_init?:
src/xen_common.c:102: warning: pointer targets in passing argument 1 of 
?xmlXPathCompile? differ in signedness
src/xen_common.c:105: warning: pointer targets in passing argument 1 of 
?xmlXPathCompile? differ in signedness
src/xen_common.c: In function ?call_raw?:
src/xen_common.c:243: warning: pointer targets in passing argument 2 of 
?parse_result? differ in signedness
src/xen_common.c: In function ?is_container_node?:
src/xen_common.c:293: warning: pointer targets in passing argument 1 of 
?strlen? differ in signedness
src/xen_common.c:293: warning: pointer targets in passing argument 1 of 
?__builtin_strcmp? differ in signedness
src/xen_common.c:293: warning: pointer targets in passing argument 1 of 
?strlen? differ in signedness
src/xen_common.c:293: warning: pointer targets in passing argument 1 of 
?__builtin_strcmp? differ in signedness
src/xen_common.c:293: warning: pointer targets in passing argument 1 of 
?__builtin_strcmp? differ in signedness
src/xen_common.c:293: warning: pointer targets in passing argument 1 of 
?__builtin_strcmp? differ in signedness

2. The test program failed to link because the libcurl -l linker flags
   were surrounded in -Wl,--as-needed. The fix was simply to re-arrange
   the linker flags from

    $(CC) $(LDFLAGS) -o $@ $<O-L src -lxen

   To:

    $(CC) -o $@ $< $(LDFLAGS) -L src -lxen

On Tue, Aug 08, 2006 at 05:00:23PM +0100, Ewan Mellor wrote:
> I've added a record type to each of the classes, such as xen_vm_record, which
> will be used for client-side storage of data fields.  I've added getters for
> these records, such as xen_vm_get_record, which return one of these.

The design of the API feels a little odd to me - there are now basically two
ways of getting at every piece of information. Either fetch a record and then
access the struct members, or call each xen_vm_get_XXX method as required. The
latter methods in their current impl result in an XML-RPC roundtrip on every
call which seems rather undesirable. Given this performance overhead, under 
what circumstances would you anticipate one wanting to use the xen_vm_get_XXX 
methods at all - accessing struct members is just as easy & less overhead?

Following on from this can you clarify how the apps are supposed to approach
error handling. The xen_session struct has an 'error_description' array of
strings, but its unclear to me when one is supposed to check this? All the
setter methods have a 'void' return type, and there is no explicit return
code indicating errors for the getters (although you could check for NULL
in some of them, others returning an enum aren't so clear), so how do youy
tell whether a method succeeded or failed ? From a cursory glance at the impl
of the xen_vm.c class it looks like every method can at least have a failure
from malloc() returning NULL, but this is never checked / propagated back to
the caller.

Finally, on the much discussed topic of resource utilization stats. From 
previous discussions I was under the impression the APIs for fetching
these stats were going to be separated out from the APIs for fetching info
about an object's configuration / hardware properties. The xen_vm_record
xen_vbd_record and xen_vif_record structs all still contain the members
for utilization stats.  What is the plan for providing APIs to efficiently
retrieve these stats in a single call ? eg a xen_vm_stats() or some such
API call.

Oh actually, one further question - where/how is information about the
virtual display adapters / serial console represented ? eg VNC server 
port, SDL, and xenconsoled Pseudo TTY associated with the domain ?

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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