mirror of https://gitee.com/openkylin/libvirt.git
106 lines
5.0 KiB
ReStructuredText
106 lines
5.0 KiB
ReStructuredText
================
|
|
Project Strategy
|
|
================
|
|
|
|
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.
|
|
|
|
Language consolidation
|
|
----------------------
|
|
|
|
At time of writing libvirt uses the following languages:
|
|
|
|
C
|
|
The core libvirt library, daemons, and helper tools are all written in the C
|
|
language.
|
|
Python
|
|
Various supporting build/test scripts are written in Python, with
|
|
compatibility for Python 3.
|
|
Perl
|
|
Various supporting build/test scripts are written in Perl. It is also used
|
|
for many syntax-check inline rules
|
|
Shell
|
|
Shell is used for some simple build/test scripts. At runtime libvirt avoids
|
|
shell except when using SSH tunnels to a remote host
|
|
XSLT
|
|
The website uses XSLT for its templating system. The API documentation is
|
|
also autogenerated from an XML description using XSLT
|
|
HTML
|
|
The website documentation is all written in plain HTML. Some HTML is also
|
|
auto-generated for API documentation
|
|
Meson
|
|
The core build system uses the new Meson build system
|
|
make
|
|
The syntax-check uses make recipes
|
|
awk/sed
|
|
A number of the syntax-check inline rules involve use of awk/sed scripts
|
|
POD
|
|
The command line manual pages are typically written in Perl's POD format, and
|
|
converted to troff
|
|
|
|
The 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 Meson, shell, 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:
|
|
|
|
C
|
|
Large parts of the core libvirt library, daemons, and helper tools will
|
|
continue to make use in the C language. Integration of other languages will
|
|
be an incremental, targeted process where they can bring the greatest
|
|
benefit.
|
|
Rust / Go
|
|
Parts of the core libvirt library, daemons and helper tools are to leverage
|
|
Rust or Go or both to replace C.
|
|
Meson
|
|
The core build system is to be written in Meson.
|
|
Python
|
|
Various supporting build/test scripts are written in Python 3 compatible mode
|
|
only.
|
|
reStructuredText
|
|
The website and command man pages are to be written in RST, using Sphinx as
|
|
the engine to convert to end user formats like HTML, troff, etc
|
|
|
|
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.
|
|
|
|
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 <https://readthedocs.org/>`__. 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.
|