On Tue, Aug 08, 2006 at 08:11:07PM +0100, Daniel P. Berrange wrote:
> Wow, that's an incredible amount of code written already !
*grin* I just wanted to do enough to be able to make a create_vm call, but
that turned out to be just about all of it!
> 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:
Thanks. My older GCC obviously doesn't flag those warnings, but they look
pretty easily solved -- I think they're all where I'm using char * rather than
xmlChar * or vice versa. My intention was for all strings to be UTF-8, like
libxml2, but without exposing xmlChar at the interface, so I just need to
sprinkle some casts around.
> 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
Cool, thanks, I'll fix that.
> 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?
I can imagine you wanting to access some of the fields certainly --
Vm.memory_actual, for example, would let you cheaply monitor changes in VM
memory consumption. Of course, no every field is going to be useful as an
individual get call, but it's not clear precisely which ones they are, and
they aren't expensive to support, so I thought that we may as well throw them
all in, for simplicity's sake.
> 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 ?
The intention is that you check xen_session->ok before you use any of the
values returned by the library in your application, or before you make any
state-modifying calls on the server. You can chain together a few calls into
the library if necessary, as once ok is set to false, subsequent calls won't
actually take place. In many cases, this will degenerate to checking
xen_session->ok after each call into the library.
On that subject, the intention with the error_description array is that the
first element is a code, and any subsequent elements are the parameters to the
error message. You would look up the code in your internationalised message
database, and then substitute the parameters in appropriately. We still need
to define those codes and the parameters that match -- I've just done this on
an ad-hoc basis in the library at the moment.
> 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.
Yes, there will certainly be some failures that I haven't checked for, in
particular malloc calls. I'll be going through and checking for these kind of
things as part of the code audit that I'm going to do when they drop into Xen
pre-3.0.4.
> 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.
Yes, something like a xen_vm_stats() call is what I had in mind, though there
might be more than one, depending upon the kind of monitoring that you want to
do. Any ideas on that front?
> 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 ?
It looks like those are missing -- I'll put them on the TODO list.
Thanks,
Ewan.
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home