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

[Nicholas Rosbrook <rosbrookn@xxxxxxxxxxxx>]

> I return to the question I stated before.  At the moment, your bindings
> have the following call chain:
> 
> * DomainInfo(), hand-crafted.  Calls domainInfo().
> * domainInfo(), automaticall generated.  Calls C.libxl_domain_info().
> 
> The in-tree bindings have the following call chain:
> 
> * DomainInfo(), hand-crafted.  Calls C.libxl_domain_info().
> 
> Since DomainInfo() is hand-crafted in both cases, what's the advantage
> of having domainInfo() at all?

Point well taken.

> So just to clarify terminology: The IDL is the description language
> itself, which at the moment only contains information about the libxl
> structures.  We have generators for various C bits of libxl which read
> the IDL and spit out boilerplate C.  The idea would be that we write a
> new generator for Go which reads the IDL and spits out boilerplate Go.

Yes, I know. Sorry for the strange phrasing. I'll try again:

From what I understand, the IDL is only used to generate libxl types, and
the boiler-plate init, dispose, etc. functions. However, if we want to have a
generator that produces Go code that calls libxl functions, those function
signatures must be known during code generation. However, the description
of those functions is outside the scope of the IDL.

So, in order to write such a generator we would need to either:

1. Expand the IDL (significantly) so that function signatures could be described
in the general case.

2. Parse the C code.

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 looked at the thing about naked returns, and didn't really understand
> it; but anyway I'm happy to have things modified to be more Go-like.  I
> definitely "speak" Go with a funny accent.

TL;DR: Naked returns exist; don't use them (with the exception of defer'd 
closures if necessary).

> Can I say -- I've been going open-source for so long, that I feel almost
> unsafe when nobody reviews my stuff.  Most of this code was written by
> me and reviewed by nobody (since I was the only person interested); it's
> good to have someone else take a critical look at it.

Makes sense to me. Glad to be involved :)

> And if we had a an IDL for the libxl functions, we could have it
> generate the code above for the vast majority of cases.

I guess that answers my question above.

> If we wrote a generator from the IDL, we could make it smart enough to
> use []Disks as the type there, and make the marshallers know how to use
> num_disks to appropriately size the resulting slice and copy the right
> number of values across.  To do that with c-for-go, we'd have to do a
> lot of work teaching it what to do, if that's even possible.

Good point. AFAICT there isn't a way to provide such information to c-for-go.

> So you mean, for example, after DomainInfo() calls DomInfo.Deref(), it
> will then call libxl_dominfo_dispose() on the C struct?

Yes.

> Right, and personally I'm not in principle opposed to using c-for-go, if
> it can be made to generate code the way we like it.  My main fear is
> that we'll spend a bunch of time tweaking c-for-go, and after going back
> and forth and investing a lot of time in it, we'll end up either 1)
> giving up and writing our own generator anyway, or 2) accepting
> something sub-optimal because it's the best thing we could make c-for-go do.

I agree, those are legitimate concerns for using c-for-go. OTOH, one concern
I have for a custom generator is that it is indeed custom, and maybe wouldn't
be of much use outside of libxl. It would be great if the extra work in writing 
a new
generator meant that it could be used by other projects with similar needs. 
However,
I understand that concern may not be shared by others.

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?

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