I did some investigation on python bindings. It seems the best way today is
using ctypes.
There are a few tools to autogenerate the bindings, but in my mind, the best way
is: generate at first time and then make some changes and maintain it manually.
I think user readability is most important.
And I was thinking xl should written in python.
Thanks,
Zhigang
On 06/28/2010 07:30 PM, Vincent Hanquez wrote:
> On 28/06/10 10:59, Ian Campbell wrote:
>> Not really a comment on this patch as such but more a related thought...
>> How many language bindings do we think there are going to be and how
>> much effort do we expect it would be keeping them all (or even just the
>> interesting subset) up to date?
>>
> I'm not sure if you're asking generally in terms of languages or in
> terms of bindings. I think from the point of view of bindings, that was
> the only thing left that required a binding. in terms of language, I
> don't really know if anyone is going to add some python bindings or not.
> it depends if xend is going to die, or is going to be ported.
>
> effort wise, it's hard to answer since it depends on lots of variables.
> for example, API stability of libxenlight.
>
>> Is it worth investing the time up front to define a (simple) IDL and to
>> generate the C header and language bindings from that?
>>
>> Are there any existing IDLs which would meet our needs?
>>
> Theoretically, yes. pratically there's no IDL that i know of, that
> generate anything remotely close to be good or even useful. (it's maybe
> no surprise that all the python bindings are not autogenerated either)
>
> swig seems to generate bindings really close to the C layer which make
> it quite annoying since the ml glue code become quick thick and quite
> annoying to write (converting back and forth types) and i've never
> actually tested the output of swig, and last time i tried camlIDL on a
> simple example, it generated a code that would segfault.
>
> one more thing about generic bindings generator, is that it's hard to
> provide nice and clean interfaces. most of the time you stay really
> close to the C layer, which defeat the whole point of using a high level
> language for the user.
>
> FYI, I've rewritten a little program to help me generate the bindings
> actually, but yet, it's quite painful to get right (and it's not in any
> Xen-friendly language either), and in the end i decided to take some of
> the output and fix it up by hand. in any case, it's really really far
> from having a automatic "./program idl > code" step in the code.
>
>> the libxl interface from needing to know enough about each language to
>> fixup the bindings (or else they may break the build). At least in the
>> normal case where the change does not require a change to the IDL then a
>> simple regeneration should be enough to update the bindings for the
>> change.
>>
> hopefully in most cases, as long as everything doesn't change too badly,
> adding fields is relatively easy even for someone that doesn't know ocaml.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home