On 7/30/19 2:11 PM, Nicholas Rosbrook wrote: > 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 off-line already. > > So far, these are the topics of discussion: > > - Code generation: Should the Go bindings be generated from the IDL? Or should > an existing cgo generator like c-for-go [1] be leveraged? > > - What does the minimal viable Go package look like? IMO it should be able to > create > and destroy domains, attach and detach network and disk devices, list > domains, > and convert domid to name and vice versa. It is also important that the > exported > APIs reflect idiomatic Go.
I'm not sure why "MVP" is important per se -- I expect everyone will make sure to implement the bits they think are critical; and how much of the rest gets implemented will depend on motivation, time, difficulty, &c. > - Challenges surrounding hypervisor versioning, go modules, etc. The main thing here is to make sure that we can avoid "breaking" changes in the future, when we implement new functionality. For instance, the choice of package name -- `golang.xenproject.org/...`, was chosen so that we could actually put something at golang.xenproject.org at some point. Deciding how to do package versioning might be important too -- e.g., should we have the package version for a release be equivalent to the underlying Xen version, or is there a better numbering scheme? And although we don't need to do loadable plugins to begin with, it would be good to take a look at what that might look like, so that (if possible) we can make sure we can add them later transparently, without any breaking changes. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
