Re: [Xen-devel] [RFC] Generating Go bindings for libxl

[Nicholas Rosbrook <rosbrookn@xxxxxxxxxxxx>]

> With that said, what are your expectations for the generated Go code at this 
> point?
> Do you think we should try to generate the pieces that call into libxl? Or, 
> do you think
> the code generation should be limited to the structs and boiler-plate C <-> 
> Go "type
> marshaling?"

[...]

> I think we have a decent enough idea for what a c-for-go version of this 
> might look like. So,
> what are the next steps in exploring the custom generator route?

Sorry to answer my own question, but I wanted to follow up with some thoughts I 
came up
with after I sent my last email.

I think maybe we should take the simpler approach. Meaning, the Go package 
would be
constructed as follows:

1. Generated code for Go types that are analogous to the C libxl types. The IDL 
should
already be able to provide enough information for a simple Go code generator 
(like gentypes.py).

2. Generated code to handle the marshaling between the pure-Go types and the C 
types. We
could tailor this piece to address the short-comings of c-for-go, e.g. the 
num_disks issue, preventing
use-after-free, etc.

3. Hand-written wrappers. As you stated before, there is not much difference 
between the in-tree
bindings calling C.libxl_domain_info, and my wrappers calling domainInfo() 
(besides the additional
layer in mine). And, we agree that writing those simple wrappers is pretty 
painless.

I think this is more or less what you have been suggesting, but I wanted to 
articulate the point that
I think if we go with a custom generator, we should not try do as much as 
c-for-go is trying do.

Thoughts on that?

-NR
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel