Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qmp: add Monitor which uses cgo bindings to interact with libvirt #30

Open
mdlayher opened this issue May 2, 2016 · 4 comments
Open

Comments

@mdlayher
Copy link
Contributor

mdlayher commented May 2, 2016

The libvirt-go cgo bindings will likely provide the best stability and error handling capabilities for interacting with libvirt, so we should add the ability to use them. They must be guarded by a build tag.

If built without the tag, all cgo operations will return error stubs.

@mdlayher mdlayher changed the title Add qmp.Monitor which uses cgo bindings to interact with libvirt qmp: add Monitor which uses cgo bindings to interact with libvirt May 3, 2016
@robertojrojas
Copy link
Contributor

I've been looking into this issue and here is one idea on addressing the build tag guard.
I thought about creating 3 files like so:
libvirtgo.go (this file contains implementation methods entry point for Monitor, etc...
It will call the correct implementation method based on the GOOS where it's built)

libvirtgo_linux.go (this file contains the calls to libvirt-go package)

libvirtgo_others.go [build tag: // +build !linux](this file contains operations returning error stubs)
Of course, there will be *_test.go files with the corresponding tests.

Does this make sense?

@mdlayher
Copy link
Contributor Author

Yep, seems reasonable to me. I'm happy as long as it compiles on all platforms, even if every method returns an error when not running on Linux.

@robertojrojas
Copy link
Contributor

I'm getting closer to a PR for this issue. As for the dependency to the libvirt-go package, would Go 1.5+ vendoring suffice?

@mdlayher
Copy link
Contributor Author

Since we are providing packages and not an application, we don't explicit vendor our dependencies. Importing it without vendoring is fine, especially because both repositories belong to DigitalOcean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants