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

[George Dunlap <george.dunlap@citrix.com>]

On 7/30/19 2:11 PM, Nicholas Rosbrook wrote:
> Hello,
> 
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would like to open
> a discussion around the development of Go bindings for libxl. George Dunlap,
> Nicolas Belouin and I have had some discussion off-line already.
> 
> So far, these are the topics of discussion:
> 
> - Code generation: Should the Go bindings be generated from the IDL? Or should
>   an existing cgo generator like c-for-go [1] be leveraged?

Well a couple of general considerations:

* The IDL describes things at a more semantic level; it can be
arbitrarily extended with as much information as needed to allow the
generators to do their work.  And we have more control over the output:
in particular, we know we can enforce calling conventions such as
calling libxl_<type>_init() and libxl_<type>_dispose().

* AFAICT at the moment, the IDL is only used to generate C code, not for
any other languages; and only contains information about types, not
about the function signatures.  So using the IDL for "foreign" language
bindings is actually a new use case we haven't done before.

* Work enriching the IDL should have cross-over benefits into other
languages (for instance, ocaml, should XenServer ever decide to port
xapi to use libxl).  Such languages will either have no such
c-to-<language> translator, or will have a very different one.

* At the risk of falling into "NIH", adding any external dependency is
somewhat of a risk. While the c-for-go project seems reasonably stable,
it's not part of the core Go toolset, and doesn't seem to be backed by a
major corporation with a vested interest in keeping it going.  What
happens if the maintainer decides to move on in 4 years?  Making a
custom generator is a little bit of extra work, but saves us having to
potentially deal with abandoned upstream tooling down the line.

* FWIW we don't need to parse any C code to use the IDL, we can use
python's native parser.

All that said, the first question I think is, what the generated code
needs to look like.  Then, if c-for-go can be configured to do that,
then we can consider it; otherwise, making our own generator from the
IDL will be the only option.

Out of curiosity, have you looked at the existing in-tree bindings?  Any
particular opinions?

There are two major differences I note.

First, is that in your version, there seems to be two layers: libxl.go
is generated by c-for-go, and contains simple function calls; e.g.:
domainInfo(), which takes a *Ctx as an argument and calls
C.libxl_domain_info.  Then you have libxl_wrappers.go, which is written
manually, defining DomainInfo as a  method on Ctx, and calls domainInfo().

So you're writing the "idiomatic Go" part by hand anyway; I don't really
see why having a hand-written Go function call an automatically
generated Go function to call a C function is better than having a
hand-written Go function call a C function directly.

The other difference is in the handling of nested structures.  c-for-go
seems to generate a struct which has the core C struct inside it, as
well as a Go-like translation of that struct, and methods on that struct
which will copy things into and out of the C struct.

But rather than doing a "deep copy" for pointers within a struct, it
simply copies and casts the pointer from inside the struct to a pointer
outside the struct.

In fact, there's a Go-like clone of libxl_domain_config, but none for
the elements of it; DeviceDisk, for instance, is simply defined as
C.libxl_device_disk, and config->disks simply copied to the Disks
element of the struct.  That's just all wrong -- it's actually a C
array; Go can only access the first element of it.  How are you supposed
to create a domain with more than one disk?

Furthermore, these pointers are not re-set to `nil` after <type>.Free()
is called.  This just seems very dangerous: It would be way to easy to
introduce a use-after-free bug.

And keeping these C pointers around makes things very tricky, as far as
making sure they get freed.

The in-tree bindings generally only create C structures temporarily, and
do a full marshal and unmarshall into and out of Go structures.  This
means a lot of copying on every function call.  But it also means that
the callers can generally treat the Go structures like normal Go
structures -- they don't have to worry about keeping track of them and
freeing them or cleaning them up; they can let the GC deal with it, just
like they deal with everything else.

Which more or less brings me to the core design decision we have to
make: dealing with pointers to / in transient structures (as opposed to
long-lived structures like libxl_ctxt or xentoollogger).  It seems to me
we have a couple of options:

1. Keep separate structures, and do a full "deep copy", as the in-tree
bindings do.  Advantage: Callers can use GC like normal Go functions.
Structure elements are translated to go-native types. Disadvantage:
Copying overhead on every function call.

2. Use C types; do explicit allocate / free.  Advantage: No copying on
every function call.  Disadvantage: Needing to remember to clean up / no
GC; can't use Go-native types.

3. Nest one structure inside the other, and do a marshall only when one
of them changes.  Advantage: Copying only when one of the two sides
changes, rather than every function call; c-for-go already generates a
lot of the marshalling / unmashalling code.  Disadvantage:  Need to do a
full copy whenever one side changes (which in libxl's case will be
almost every function call); Needing to remember to treat pointers
carefully; complicated management of pointers; c-for-go implementation
probably not easily integrated with libxl_<type>_dispose() calling
discipline.

4. Attempt to use SetFinalizer() to automatically do frees / structure
clean-up [1].  Advantage: No / less copying on every function call, but
can still treat structures like they'll be GC'd.  Disadvantage: Requires
careful thinking; GC may not be as effective if C-allocated memory
greatly exceeds Go-allocated memory; can't use Go-native types for elements.

[1]
http://rabarar.github.io/blog/2015/09/29/cgo-and-destructors-for-managing-allocated-memory-in-go/

c-for-go seems to take the worst bits of #1 and #2: It requires explicit
allocate / free, but also actually does a full copy of each structure
whenever one "half" of it changes.

I think I'm coming more and more to the conclusion that I don't like
what c-for-go produces in libxl's case. :-)

On the whole, I still think #1 is the best option.  Thoughts?

 -George

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