[PATCH] golang: Update generated files after libxl_types.idl change

George Dunlap posted 1 patch 6 months, 1 week ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/xen tags/patchew/20200522094956.3611661-1-george.dunlap@citrix.com
Maintainers: Ian Jackson <ian.jackson@eu.citrix.com>, George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>
tools/golang/xenlight/helpers.gen.go | 10 ++++++++++
tools/golang/xenlight/types.gen.go   |  3 +++
2 files changed, 13 insertions(+)

[PATCH] golang: Update generated files after libxl_types.idl change

Posted by George Dunlap 6 months, 1 week ago
c/s 7efd9f3d45 ("libxl: Handle Linux stubdomain specific QEMU
options.") modified libl_types.idl.  Run gengotypes.py again to update
the geneated golang bindings.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
CC: Nick Rosbrook <rosbrookn@ainfosec.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wl@xen.org>
---
 tools/golang/xenlight/helpers.gen.go | 10 ++++++++++
 tools/golang/xenlight/types.gen.go   |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go
index 109e9515a2..b5bd0de830 100644
--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -1163,6 +1163,9 @@ func (x *DomainBuildInfo) fromC(xc *C.libxl_domain_build_info) error {
 	if err := x.DeviceModelStubdomain.fromC(&xc.device_model_stubdomain); err != nil {
 		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
 	}
+	x.StubdomainMemkb = uint64(xc.stubdomain_memkb)
+	x.StubdomainKernel = C.GoString(xc.stubdomain_kernel)
+	x.StubdomainRamdisk = C.GoString(xc.stubdomain_ramdisk)
 	x.DeviceModel = C.GoString(xc.device_model)
 	x.DeviceModelSsidref = uint32(xc.device_model_ssidref)
 	x.DeviceModelSsidLabel = C.GoString(xc.device_model_ssid_label)
@@ -1489,6 +1492,13 @@ func (x *DomainBuildInfo) toC(xc *C.libxl_domain_build_info) (err error) {
 	if err := x.DeviceModelStubdomain.toC(&xc.device_model_stubdomain); err != nil {
 		return fmt.Errorf("converting field DeviceModelStubdomain: %v", err)
 	}
+	xc.stubdomain_memkb = C.uint64_t(x.StubdomainMemkb)
+	if x.StubdomainKernel != "" {
+		xc.stubdomain_kernel = C.CString(x.StubdomainKernel)
+	}
+	if x.StubdomainRamdisk != "" {
+		xc.stubdomain_ramdisk = C.CString(x.StubdomainRamdisk)
+	}
 	if x.DeviceModel != "" {
 		xc.device_model = C.CString(x.DeviceModel)
 	}
diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go
index df68fd0e88..15516ae552 100644
--- a/tools/golang/xenlight/types.gen.go
+++ b/tools/golang/xenlight/types.gen.go
@@ -509,6 +509,9 @@ type DomainBuildInfo struct {
 	MaxMaptrackFrames     uint32
 	DeviceModelVersion    DeviceModelVersion
 	DeviceModelStubdomain Defbool
+	StubdomainMemkb       uint64
+	StubdomainKernel      string
+	StubdomainRamdisk     string
 	DeviceModel           string
 	DeviceModelSsidref    uint32
 	DeviceModelSsidLabel  string
-- 
2.25.1


Re: [PATCH] golang: Update generated files after libxl_types.idl change

Posted by Wei Liu 6 months, 1 week ago
On Fri, May 22, 2020 at 10:49:56AM +0100, George Dunlap wrote:
> c/s 7efd9f3d45 ("libxl: Handle Linux stubdomain specific QEMU
> options.") modified libl_types.idl.  Run gengotypes.py again to update

libxl_types.idl.

> the geneated golang bindings.
> 

Can we perhaps add a dependency on golang's side such that it can be
auto-generated in the future?

In any case

Acked-by: Wei Liu <wl@xen.org>

(I haven't looked at the generated code)

Re: [PATCH] golang: Update generated files after libxl_types.idl change

Posted by George Dunlap 6 months, 1 week ago

> On May 22, 2020, at 11:01 AM, Wei Liu <wl@xen.org> wrote:
> 
> On Fri, May 22, 2020 at 10:49:56AM +0100, George Dunlap wrote:
>> c/s 7efd9f3d45 ("libxl: Handle Linux stubdomain specific QEMU
>> options.") modified libl_types.idl.  Run gengotypes.py again to update
> 
> libxl_types.idl.
> 
>> the geneated golang bindings.
>> 
> 
> Can we perhaps add a dependency on golang's side such that it can be
> auto-generated in the future?

Indeed, I’m trying to think of a good solution to this.

 -George