This document attempts to outline the libvirt project strategy for the near future. Think of this as a high level vision or to-do list setting the direction for the project and its developers to take.
At time of writing libvirt uses the following languages:
configure, generated by autoconf, is a shell script.
Shell is also used for some simple build/test scripts. At runtime
libvirt avoids shell except when using SSH tunnels to a remote
hostconfigure script uses a large number of
M4 macros to generate its contentThe wide range of languages used present a knowledge burden for developers involved in libvirt, especially when there are multiple languages all used in the same problem spaces. This is most notable in the build system which uses a combination of shell, M4, make, automake, awk, sed, Perl and Python, with debugging requiring understanding of the interactions between many languages. The popularity of Perl has declined, while Python has become more popular. This directly influences the amount and quality of contributions that can be expected for programs written in the respective languages.
The C language has served libvirt well over the years, but its age shows giving rise to limitations which negatively impact the project in terms of code quality, reliability, and efficiency of development. Most notably its lack of memory safety means that many code bugs become trivially exploitable security flaws or denial of service. The lack of a high level portable runtime results in a lot of effort being spent to ensure cross platform portability. The modern languages Rust and Go provide viable options for low level systems programming, in a way that is not practical with other common languages such as Python and Java. There is thus a desire to make use of either Rust or Go, or a combination of both, to incrementally replace existing use of C, and also for greenfield development.
With this in mind the libvirt project has set a vision for language usage in the future:
Some notable points from the above. Whether the core library / daemons will use Rust or Go internally is still to be decided based on more detailed evaluation to identify the best fit. The need to link and embed this functionality in other processes has complex interactions both at a technical and non-technical level. For standalone helper tools, either language is viable, but there are fewer concerns around interactions with other in-process code from 3rd parties. Thus a different decision may be made for daemons/libraries vs tools. Any rewrite proposed for existing functionality will have to weigh up the benefits of the new code, against the risk of introducing regressions with respect to the previous code.
The Meson build system is written in Python 3. This directly informs the choice of Python 3 as the language for all supporting build scripts, re-inforcing the other benefits of Python over Perl, Shell, M4, automake, etc. There is no intention to support Python 2 given Meson's requirement for Python 3.
Using the RST format for documentation allows for the use of XSLT to be eliminated from the build process. RST and the Sphinx toolkit are widely used, as seen by the huge repository of content on Read The Docs. The ability to embed raw HTML in the RST docs will greatly facilitate its adoption, avoiding the need for a big bang conversion of existing content. Given the desire to eliminate Perl usage, replacing the use of POD documentation for manual pages is an obvious followup task. RST is the obvious choice to achieve alignment with the website, allowing the man pages to be easily published online with other docs. It is further anticipated that the current API docs generator which uses XSLT to convert the XML API description would be converted to something which generates RST using Python instead of XSLT.