10:19 a.m.
Hello,
I am currently implementing a libvirt driver for my company's proprietary custom
hypervisor. I have used the VMware driver as a design template, since it is interfacing a
closed-source hypervisor as well.
Ultimately, as we approach a minimally-usable implementation, we would like to upstream
our driver mods to libvirt source. What is the process to do so? This is all new to me and
my organization.
For some brief background info, I am maintaining a git repo of our new code, plus ed
scripts to modify libvirt source files. I am using quilt to create patches which are given
to dpkg-buildpackage to create our own .deb packages. (I am working on Ubuntu at the
moment; soon I will try to address repackaging rpms for CentOS).
I appreciate any tips, pointers, suggestions, etc.
12:16 p.m.
On 19.05.2016 17:19, Scott Bissett wrote:
Hello,
I am currently implementing a libvirt driver for my company's proprietary custom
hypervisor. I have used the VMware driver as a design template, since it is interfacing a
closed-source hypervisor as well.
Ultimately, as we approach a minimally-usable implementation, we would like to upstream
our driver mods to libvirt source. What is the process to do so? This is all new to me and
my organization.
Hey, glad to hear you want to implement new driver.
Firstly, I guess you are familiar with our driver structure already:
http://libvirt.org/api.html
Then, all you need to do is to create new subdir: src/$hypervisor and
place all your files there. Ideally,
src/$hypervisor/$hypervisor_driver.c would be the entry point for the
driver as it would will virHypervisorDriver structure with implemented APIs.
It's okay to look around how other drivers do it and mimic their
approach. The fact that the code is merged says we were okay with their
approach once.
For some brief background info, I am maintaining a git repo of our
new code, plus ed scripts to modify libvirt source files. I am using quilt to create
patches which are given to dpkg-buildpackage to create our own .deb packages. (I am
working on Ubuntu at the moment; soon I will try to address repackaging rpms for CentOS).
ed scripts? Wow, this may be even bigger mystery than esx driver where
half of the driver is auto generated :-)
What we prefer are patches sent to the list (generated by git
format-patch and send by git send-email). It's all covered here:
http://libvirt.org/hacking.html
Yes, some items there are outdated (e.g. nobody generates patches by
'diff'), but use your gut feeling and you should do good.
Also, please make sure that 'make syntax-check' and 'make check' passes
after each single patch of yours. Happy coding!
Michal
4:02 a.m.
On Thu, May 19, 2016 at 03:19:50PM +0000, Scott Bissett wrote:
Hello,
I am currently implementing a libvirt driver for my company's proprietary
custom hypervisor. I have used the VMware driver as a design template,
since it is interfacing a closed-source hypervisor as well.
Ultimately, as we approach a minimally-usable implementation, we would like
to upstream our driver mods to libvirt source. What is the process to do so?
This is all new to me and my organization.
Even if what you have is not yet minimally-usable, I'd encourage you to
send work in progress patches for review on the list. This will help us
identify any integration / design mistakes before you spend too much time
going down a possible blind ally.
For some brief background info, I am maintaining a git repo of our
new code,
plus ed scripts to modify libvirt source files. I am using quilt to create
patches which are given to dpkg-buildpackage to create our own .deb packages.
(I am working on Ubuntu at the moment; soon I will try to address repackaging
rpms for CentOS).
I appreciate any tips, pointers, suggestions, etc.
Make sure you're familiar with the style guidelines in:
http://libvirt.org/hacking.html
especially that make check & make syntax-check all pass for each individual
patch.
Generally we recommend sending patches using 'git send-email', with the
patches created against latest GIT master, not some older existing release.
Trying to keep patches split up into small self-contained chunks is also
desirable to help with review. Since it is a hypervisor most reviewers won't
know about it, it'll also be helpful if you give an overview of your hypervisor
architecture & API, so we understand why the code is taking an approach that
it does.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
3108
days inactive
3109
days old
2 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Michal Privoznik -
Scott Bissett