On 9/4/19 5:52 PM, George Dunlap wrote:
> On 9/4/19 1:36 AM, Nicholas Rosbrook wrote:
>> 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 main exception is that I am not certain how the `KeyedUnion` type from
>> the IDL
>> should be translated for Go. One option is to do something similar to the
>> `oneof` field
>> in gRPC's protobuf messages[2]. Essentially, we would define a separate
>> struct for each
>> of the structs that belong to the union. Then, where a union would be used
>> in C, we use
>> an interface type which the previously defined structs implement.
>
> 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.
>
> The really annoying thing is that with the "interface-as-union", we
> can't use anonymous types: we'll have to explicitly define the
> {parent-struct} x {union-key} as a distinct type, and the is$TYPE()
> method on each one.
>
>> E.g.
>>
>> type isDomainTypeStruct interface {
>> isDomainTypeStruct()
>> }
>
> The interface type itself will need to be exported, right? (Obviously
> we don't want to export the defining method.)
>
>> type domainTypeHVMStruct struct {
>> ...
>> }
>
> So you've named the struct after the name of the key (libxl_domain_type)
> and the key value (hvm); but I don't think that's sufficient. Already
> there are two different structures indexed by libxl_channel_connection:
>
> typedef struct libxl_device_channel {
> libxl_domid backend_domid;
> char * backend_domname;
> libxl_devid devid;
> char * name;
> libxl_channel_connection connection;
> union {
> struct {
> char * path;
> } socket;
> } u;
> } libxl_device_channel;
>
> typedef struct libxl_channelinfo {
> char * backend;
> uint32_t backend_id;
> char * frontend;
> uint32_t frontend_id;
> libxl_devid devid;
> int state;
> int evtch;
> int rref;
> libxl_channel_connection connection;
> union {
> struct {
> char * path;
> } pty;
> } u;
> } libxl_channelinfo;
>
>
> (Note that in one, `socket` is defined, and in the other, `pty` is
> defined. I'm not sure that's not a bug, but anyway, that's what the IDL
> allows.)
>
> And there's no reason, theoretically, we couldn't have the following:
>
> ("u1", KeyedUnion(None, libxl_channel_connection, "connection",
> [/* One set of types */,
> ])),
> ("u2", KeyedUnion(None, libxl_channel_connection, "connection2",
> [/* A second set of types set of types */,
> ])),
>
> So we need to include the element name as well. But actually, I suppose
> that means we don't actually need to include the type, since the element
> name will be unique.
>
>> func (d domainTypeHVMStruct) isDomainTypeStruct() {}
>>
>> type DomainBuildInfo struct {
>> ...
>> Type DomainType
>> dts isDomainTypeStruct
>> }
>
> ...and then I'm afraid you'd need to have 'Dts' (should be exported,
> right?) instead by the element specified by the IDL; so 'U' in all the
> current cases.
>
> This gives us:
>
> type DomainBuildInfoU interface {
> isDomainBuildInfoU()
> }
>
> type DomainBuildInfoUHvmstruct {
> // ...
> }
Unfortunately this would mean the type assertion would be pretty long as
well:
hvm := di.TypeUnion.(xenlight.DomainBuildInfoTypeUnionHvm)
hvm.[element]
Compared to C:
di.u.hvm.[element]
But unfortunately I don't think there's a way around that; that's just a
limitation of Go.
-George
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
