On 8/1/19 7:59 PM, Nicholas Rosbrook wrote: >> 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.
I was going to say, the idea of adding function signatures to the IDL was just "exploring the state space" of approaches. Parsing the existing IDL to spit out Go structures and marshalling should be reasonably straightforward. Designing an IDL for the functions is a fairly large design project, with all sorts of exciting <strikethrough>bike sheds to paint</strikethrough> important design decisions to make along the way: probably something to attempt if / when we determine that it's worth the cost. IOW, in response to GP, I was going to counter-suggest what you suggest in this email. :-) Are you up for taking a stab at something like `gengotypes.py`? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
