What should we do for contributing a new hypervisor driver?
Hello. This is my first time of sending e-mail to this mailing list. We are developing a new hypervisor driver. What should we prepare for contributing it? So far, we implemented the following functions. Are there any other things we should prepare? .connectOpen .connectClose .domainCreateXML .domainCreate .domainCreateWithFlags .domainShutdown .domainShutdownFlags .domainDestroy .domainDestroyFlags .connectNumOfDomains .connectListDefinedDomains .connectNumOfDefinedDomains .connectListDomains .connectListAllDomains .domainGetInfo .domainGetState .connectIsAlive .domainHasManagedSaveImage .domainGetXMLDesc .connectGetType .connectGetVersion .domainLookupByID .domainLookupByUUID .domainLookupByName .domainIsActive .domainIsPersistent .domainGetOSType .domainUndefine .domainUndefineFlags Motohiro Kawahito, Commercial Systems, IBM Research - Tokyo 19-21 Nihonbashi, Hakozaki-cho Chuo-ku, Tokyo 103-8510, Japan
On Mon, Jul 12, 2021 at 03:54:58PM +0900, Motohiro Kawahito wrote:
Hello. This is my first time of sending e-mail to this mailing list. We are developing a new hypervisor driver. What should we prepare for contributing it? So far, we implemented the following functions. Are there any other things we should prepare?
Aside from the actual functionality there are things like - All existing unit tests should pass of course - Ideally you should add unit tests for your driver too, especially focus on the conversion between the libvirt XML format, and whatever config format your hypervisor needs. eg qemuxml2argvtest.c is what QEMU needs, while libxlxml2domconfigdata.c shows a different approach used by Xen - Make sure the code style looks the same as normal code style for other parts of libvirt. We have 'syntax-check' suite tat runs as part of the tests to validate alot of this. - Add any build pre-requisites to the container files to let it build in GitLab CI - Making sure it passes when run in GitLab CI. - Possibly changes to the RPM spec (if the hypervisor is relevant)
.connectOpen
...snip...
.domainUndefineFlags
These are more than enough APIs for a first contribution. Better to get the initial framework for a driver merged sooner, and then do additional API coverage as follow on patches. Don't worry too much about trying to get everything 100% perfect first time around. No one ever will. Even if you don't think the code is quite ready, it is still beneficial to send patches, marked as 'WIP' or 'RFC'. We can give you more direct feedback on any areas that would need work before being mergable, and spot any significant problems before you spend too much time. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (2)
-
Daniel P. Berrangé -
Motohiro Kawahito