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/
Home Products Support Community News


[Xen-devel] Re: [PATCH,v2]: add libxl python binding

To: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH,v2]: add libxl python binding
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 10 Sep 2010 17:45:11 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Fri, 10 Sep 2010 09:46:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1284133746.17452.172.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1284133746.17452.172.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-09-10 at 16:49 +0100, Gianni Tedesco wrote:
> Changes since v1:
>  - Interpret keyword arguments in initializers: eg. xl.device_pci(bus=1, 
> dev=2, fn=3)
>  - Implement domain pause/unpause/rename/pci_add/pci_del and pci_parse
>  - Proper type-checking in all (I hope) code-paths
>  - Improve API for accessing auto-generated code and types
> Changes since RFC:
>  - split auto-generated code in to c and h files
>  - un-break the build system
>  - fix ocaml binding due to libxl API change
>  - lot's of tidy-ups too numerous to mention
> -----8<---------------------------------------------------------------
> Introduce python binding for libxl. The binding is not yet complete but
> serveral methods are implemented and tested. Those which are implemented
> provide examples of the two or three basic patterns that most future
> methods should follow.
> Over 5,000 lines of boilerplate is automatically generated to wrap and
> export all relevant libxl structure definitions. There are a few places
> where such code cannot be fully auto-generated and special hooks are
> declared and stubbed where, for example, conversion between
> libxl_file_reference and a python file object is required.

I'm not qualified to comment on the actual generated bindings themselves
but the tiny bit which remains looks good to me.

One perhaps interesting tip:
> +    funcs="""static void Py%s_dealloc(Py_%s *self)
> +{
> +%s    self->ob_type->tp_free((PyObject *)self);
> +}
> +"""%((ty.rawname, ty.rawname, dtor) + tuple(ty.rawname for x in range(5)))

String formatting in python can take a dictionary and then %(foo)s will
expand by looking for the key 'foo' in the dict which would likely
simplify (and help self-document) stuff with this pattern and get rid of
the "x in range 5" stuff. I bet you had a hell of a job lining up all
the %s's with their arguments correctly ;-)

"""static void Py%(rawname)s_dealloc(Py_%(rawname)s... etc
""" % {'rawname': ty.rawname, 'dtor': dtor... etc}


I also think you could get rid of the long """ string containing hand
written helpers by putting all that stuff in a pyxl.h and/or xl.c. I'd
much prefer to edit the hand-written C code in a .h file where syntax
highlighting will work properly etc. If you generate the relevant
prototypes correctly then declaration shouldn't be too much of an issue.


Xen-devel mailing list