> Ok, in that case let’s just leave the struct empty.
Ok, sounds like a plan.
> I think we basically have three options:
>
> 1. Try to arrange it so that the “zero” values correspond to “default” values
> in libxl; i.e., have DevID 0 -> libxl_devid -1, DevID 1 -> libxl_devid 0,
>
> 2. Add
> On Oct 24, 2019, at 8:54 PM, Nick Rosbrook wrote:
>
>> So we *could* actually just `type KeyValueList struct { }`, and punt on
>> all these initialization questions until such time as it turns out that
>> they're needed.
>
> If there is no clear need for this type to be implemented in the
> So we *could* actually just `type KeyValueList struct { }`, and punt on
> all these initialization questions until such time as it turns out that
> they're needed.
If there is no clear need for this type to be implemented in the Go
package, then I would be in favor of not doing so. IMO, a
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define KeyValueList builtin type, analagous to libxl_key_value_list as
> map[string]string, and implement its fromC and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
From: Nick Rosbrook
Define KeyValueList builtin type, analagous to libxl_key_value_list as
map[string]string, and implement its fromC and toC functions.
Signed-off-by: Nick Rosbrook
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
tools/golang/xenlight/xenlight.go | 33
