WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: [Xen-API] New API Document and C Bindings

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Mon, 28 Aug 2006 16:13:10 -0400
Cc: Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 28 Aug 2006 13:13:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060825185821.GF7563@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

Hello!

I had a look at the much more explicit enumeration of accessor functions for each one of the defined class. I am wondering what the rationale behind some of the set-ters is. For example the VIF class has members type, device, network, VM etc. Shouldn't these be marked RO_ins and have no associated set-ters after object creation? Can you actually change the type once the object has been created or move the VIF to another VM (set_VM)? Similar on VBD.

Regards,
   Stefan

xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 08/25/2006 02:58:21 PM:


>
> Hi all,
>
> I've put a new version of the Xen Management API document and the
> corresponding C bindings on the Xen-API wiki page (and they are attached).
> There's nothing very exciting in the document -- I've just updated the todo
> list, basically.
>
> The C bindings have been updated to the new way of passing results back and
> handling errors.  The API calls now look a lot like this:
>
>     xen_vm vm;
>     if (!xen_vm_get_by_uuid(session, &vm,
>                             "00000000-0000-0000-0000-000000000000"))
>     {
>         print_error(session);
>         CLEANUP;
>         return 1;
>     }
>
> That is, you pass a pointer to the result destination, which will befilled if
> the call is successful, or NULL otherwise, and you get a boolean result from
> the actual function call to tell you whether or not an error occurred.
>
> I've also added the appropriate casts so that this code compiles under GCC 4.0
> with -Werror.
>
> Have fun hacking, and to all the Brits out there, happy holidays,
>
> Ewan.
>
> [attachment "xenapi-0.4.3.pdf" deleted by Stefan Berger/Watson/IBM]
> [attachment "libxen-src-0.4.3-2.tar.bz2" deleted by Stefan
> Berger/Watson/IBM] _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
<Prev in Thread] Current Thread [Next in Thread>