[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH,v2]: add libxl python binding
On Fri, 2010-09-10 at 18:03 +0100, Gianni Tedesco wrote: > On Fri, 2010-09-10 at 17:45 +0100, Ian Campbell wrote: > > 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); > > [...etc...] > > > +} > > > +"""%((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 ;-) > > Yeah, well, apart from the one case where it was the same thing 15 > times. But yes, I was aware of that usage but never used it before and > tbh I hacked this up real quick so there's a few warts like that. > > > e.g. > > """static void Py%(rawname)s_dealloc(Py_%(rawname)s... etc > > """ % {'rawname': ty.rawname, 'dtor': dtor... etc} > > > > 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. > > Yeah, the definitions of the genwrap__*_(get|set) funcs can move to xl.c > which makes it a lot tidier. > > With that bit of code motion done (see patch below) it could make sense > to add a few python_* attributes in libxltypes.c so that we could, for > example, say > > x = Type(..., python_methods=PyFoo_Methods, python_init=Foobar_Init) > > which would allow, eg: pci = xl.device_pci(); pci.parse("00:11.2") or > allow a non keyword initialiser, eg: pci = xl.device_pci("00:11.2") I don't know that adding language specific stuff to the IDL is any better than just recognising specific type names which would like special handling in the generator. > Anyway, I don't think this stops us getting the code in the tree cos > such things can be done in a future patch. Agreed. Two things though, firstly the patch to Makefile didn't apply for me in any version you've sent because tabs have become spaces. Might be an issue on my end though. Secondly: xen/lowlevel/xl/xl.c: In function 'fixed_bytearray_set': xen/lowlevel/xl/xl.c:164: error: implicit declaration of function 'PyByteArray_Check' xen/lowlevel/xl/xl.c:165: error: implicit declaration of function 'PyByteArray_Size' xen/lowlevel/xl/xl.c:166: error: implicit declaration of function 'PyByteArray_AsString' xen/lowlevel/xl/xl.c:166: error: assignment makes pointer from integer without a cast xen/lowlevel/xl/xl.c: In function 'fixed_bytearray_get': xen/lowlevel/xl/xl.c:195: error: implicit declaration of function 'PyByteArray_FromStringAndSize' xen/lowlevel/xl/xl.c:195: error: return makes pointer from integer without a cast error: command 'gcc' failed with exit status 1 This is with Python 2.5 (default on Debian Lenny so, unfortunately, still worth supporting). I guess PyByteArray is new in >2.5? I don't see a cunning way around it other than making MAC and UUID first class objects instead of wrappers around byte array -- does that make the syntax in the user icky? Oh, and I think you want to add the new generated files to .hgignore. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |