> The current fromC array code will do the "magic" casting and
> martialling even when num_foo variable is 0. Go crashes when doing
> the cast.
>
> Only do array marshalling if the number of elements is non-zero;
> otherwise, leave the target pointer empty (nil for Go slices, NULL for
> C arrays)
> Keyed types in libxl_types.idl can have elements of type 'None'. The
> golang type generator (correctly) don't implement any union types for
> these empty elements. However, the toC and fromC helper generators
> incorrectly treat these elements as invalid.
>
> Consider for example, libxl_channe
Hi George,
> Just going through in detail, I notice one thing about your
> implementation of Defbool: you simply copy over the value of
> libxl_defbool. The header says of libxl_defbool:
>
> * Users should treat this struct as opaque and use the following
> * defined macros and accessor functio
Hi George,
I made the changes that we discussed WRT C to Go type marshaling. See [1] for
generated code.
In addition, I took a pass at implementing Go to C type marshaling. The
generated toC functions are also in [1].
Finally, I made the necessary changes[2] to the existing xenlight.go so that
> FWIW checked with Ian after I wrote this mail, and he confirmed that
> that field (`link` in `libxl_event`) was only meant to be used
> internally, and ideally we wouldn't even have that available in the Go
> version of the struct (since it's not actually part of the public
> interface).
>
> Unf
> That looks about like we expected -- tolerable and functional, to be
> certain, but LotsOfReallyLongTypeNames.
Yeah that's definitely a down side...
> The only purpose of unions in these structures is to save space (as
> opposed to other kinds of unions are specifically designed to allow
> diff
Hi George,
I made some more progress on gengotypes.py [1].
First, I implemented the KeyedUnion translation that we talked about.
You can see an example of the generated code in [2].
Second, I took a first pass at the C-to-Go type marshaling. I defined a
"marshaler" interface in [3], which allow
> Unfortunately this would mean the type assertion would be pretty long as
> well:
> hvm := di.TypeUnion.(xenlight.DomainBuildInfoTypeUnionHvm)
> hvm.[element]
Made worse by the fact that you really should check the type assertion first:
hvm, ok := di.TypeUnion.(xenlight.DomainBuildInfoTypeUn
> Yes, I think that's really the only option. Poking around, it looks
> like a lot of different people have recommended it; and the fact that
> it's in use by gRPC means it can't be too terrible a solution.
Yeah, having worked with generated gRPC code I don't think it's too bad.
> The interface
George,
> Are you up for taking a stab at something like `gengotypes.py`?
I have was able to make a bit of progress on this over the weekend. I've started
`gengotypes.py` in my branch[1]; the portion which generates `xenlight_types.go`
(the counterpart to _libxl_types.h) is mostly working.
The
> 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`?
Yes, I think I can handle that.
-NR
___
Xen-devel mailing list
Xen-devel@lists.xenproject.
> 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
> 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:
>
> *
> 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.
Writing a custom Go code generator means that all C
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 of
15 matches
Mail list logo
