[libvirt] [PATCH] docs: attempt to document the general libvirt dev strategy

[Peter Krempa]

On Fri, Sep 20, 2019 at 15:12:01 +0100, Daniel Berrange wrote:
> There are various ideas / plans floating around for future libvirt work,
> some of which is actively in progress. Historically we've never captured
> this kind of information anywhere, except in mailing list discussions.
> In particular guidelines in hacking.html.in don't appear until a policy
> is actively applied.
> 
> This patch attempts to fill the documentation gap, by creating a new
> "strategy" page which outlines the general vision for some notable
> future changes. The key thing to note is that none of the stuff on this
> page is guaranteed, plans may change as new information arises. IOW this
> is a "best guess" as to the desired future.
> 
> This doc has focused on three areas, related to the topic of language
> usage / consolidation
> 
>  - Use of non-C languages for the library, daemons or helper tools
>  - Replacement of autotools with meson
>  - Use of RST and Sphinx for documentation (website + man pages)
> 
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>  docs/docs.html.in     |   3 +
>  docs/strategy.html.in | 143 ++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 146 insertions(+)
>  create mode 100644 docs/strategy.html.in

[...]

> +    <p>
> +      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, resulting in alot 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
> +      was 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 more likely
> +      a combination of both, to incrementally replace existing use of C, and
> +      also for greenfield development.

Please emphasise that senseless rewrite of old code, while being "memory
safe", may introduce new logic bugs which are hard to find in many cases.

It should be well justified that rewriting some functionality has clear
maintenance and upkeep benefits even when we consider the cost logic
bugs which will eventually be introduced in any refactor. This goes for
any rewrite.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190920/d0a7eb21/attachment-0001.sig>