[libvirt] Process to upstream new driver for proprietary hypervisor?
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.
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
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 :|
participants (3)
-
Daniel P. Berrange -
Michal Privoznik -
Scott Bissett