[libvirt] Process to upstream new driver for proprietary hypervisor?

Michal Privoznik mprivozn at redhat.com
Thu May 19 17:16:52 UTC 2016


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




More information about the libvir-list mailing list