docs/docs.html.in | 3 + docs/strategy.html.in | 144 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) create mode 100644 docs/strategy.html.in
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@redhat.com>
---
docs/docs.html.in | 3 +
docs/strategy.html.in | 144 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 147 insertions(+)
create mode 100644 docs/strategy.html.in
diff --git a/docs/docs.html.in b/docs/docs.html.in
index c1741c89b4..6cf09f51bc 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -128,6 +128,9 @@
<dt><a href="hacking.html">Contributor guidelines</a></dt>
<dd>General hacking guidelines for contributors</dd>
+ <dt><a href="strategy.html">Project strategy</a></dt>
+ <dd>Sets a vision for future direction & technical choices</dd>
+
<dt><a href="bugs.html">Bug reports</a></dt>
<dd>How and where to report bugs and request features</dd>
diff --git a/docs/strategy.html.in b/docs/strategy.html.in
new file mode 100644
index 0000000000..2ed5deeec6
--- /dev/null
+++ b/docs/strategy.html.in
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <body>
+ <h1>Libvirt Project Strategy</h1>
+
+ <p>
+ This document attempts to outline the libvirt project strategy for
+ the near future. Think of this as a high level vision or todo list
+ setting the direction for the project and its developers to take.
+ </p>
+
+ <h2>Language consolidation</h2>
+
+ <p>
+ At time of writing libvirt uses the following languages
+ </p>
+
+ <dl>
+ <dt>C</dt>
+ <dd>The core libvirt library, daemons, and helper tools are all written
+ in the C language.</dd>
+ <dt>Python</dt>
+ <dd>Various supporting build/test scripts are written in Python, with
+ compatibility for Python 2 and 3.</dd>
+ <dt>Perl</dt>
+ <dd>Various supporting build/test scripts are written in Perl. It is
+ also used for many syntax-check inline rules</dd>
+ <dt>Shell</dt>
+ <dd>The autoconf configure script, is essentially 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 host</dd>
+ <dt>XSLT</dt>
+ <dd>The website uses XSLT for its templating system. The API
+ documentation is also autogenerated from an XML description
+ using XSLT</dd>
+ <dt>HTML</dt>
+ <dd>The website documentation is all written in plain HTML. Some HTML
+ is also auto-generated for API documentation</dd>
+ <dt>M4</dt>
+ <dd>The autoconf configure script uses a large number of M4 macros to
+ generate its content</dd>
+ <dt>make</dt>
+ <dd>The core build system uses the traditional GNU make recipes</dd>
+ <dt>automake</dt>
+ <dd>The make recipes use automake's language extensions which are
+ then turned into regular make rules</dd>
+ <dt>awk/sed</dt>
+ <dd>A number of the syntax-check inline rules involve use of awk/sed
+ scripts</dd>
+ <dt>POD</dt>
+ <dd>The command line manual pages are typically written in Perl's POD
+ format, and converted to troff</dd>
+ </dl>
+
+ <p>
+ 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 shell, m4, make,
+ automake, awk, sed, perl and python, with debugging requiring
+ understanding of the interactions between many languages. The
+ relative popularity of the languages has implications for how easily
+ the project can attract new contributors, and the quality of the code
+ they'll be able to submit. This is most notable when comparing Perl
+ to Python, as since the start of the libvirt project, the popularity
+ and knowledge of Perl has declined, while Python has risen.
+ </p>
+ <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 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
+ 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 a combination
+ of both, to incrementally replace existing use of C, and also for
+ greenfield development.
+ </p>
+ <p>
+ With this in mind the libvirt project has set a vision for language
+ usage in the future
+ </p>
+
+ <dl>
+ <dt>C</dt>
+ <dd>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, targetted process where they can
+ bring the greatest benefit.</dd>
+ <dt>Rust / Go</dt>
+ <dd>Parts of the core libvirt library, daemons and helper tools are to
+ leverage Rust or Go or both to replace C.</dd>
+ <dt>Meson</dt>
+ <dd>The core build system is to be written in meson.</dd>
+ <dt>Python</dt>
+ <dd>Various supporting build/test scripts are written in Python 3
+ compatible mode only.</dd>
+ <dt>reStructuredText</dt>
+ <dd>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</dd>
+ </dl>
+
+ <p>
+ 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 wrt the previous code.
+ </p>
+
+ <p>
+ 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.
+ </p>
+
+ <p>
+ 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
+ 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.
+ </p>
+ </body>
+</html>
--
2.21.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-listOn 9/24/19 5:33 PM, Daniel P. Berrangé 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@redhat.com> > --- > docs/docs.html.in | 3 + > docs/strategy.html.in | 144 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 147 insertions(+) > create mode 100644 docs/strategy.html.in > + <p> > + 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 > + https://readthedocs.org/. The ability to embed raw HTML in the RST docs This could be a clickable URL. > + 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. > + </p> > + </body> > +</html> > Even though it looks like we are leaning towards Go more than Rust now (at least that's my understanding from talking to people face to face), we can mention both for now (for instance since you made NSS plugin completely unrelated it might be interesting excercise to write it in Rust/Go) Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Sep 30, 2019 at 03:27:30PM +0200, Michal Privoznik wrote: > On 9/24/19 5:33 PM, Daniel P. Berrangé 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@redhat.com> > > --- > > docs/docs.html.in | 3 + > > docs/strategy.html.in | 144 ++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 147 insertions(+) > > create mode 100644 docs/strategy.html.in > > > > + <p> > > + 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 > > + https://readthedocs.org/. The ability to embed raw HTML in the RST docs > > This could be a clickable URL. > > > + 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. > > + </p> > > + </body> > > +</html> > > > > Even though it looks like we are leaning towards Go more than Rust now (at > least that's my understanding from talking to people face to face), we can > mention both for now (for instance since you made NSS plugin completely > unrelated it might be interesting excercise to write it in Rust/Go) Yeah I think the NSS plugin is something where memory safety would be especially useful. It is loaded into every process on the host OS and has some non-trivial parsing code. I'm not convinced that we'd want to use Go for it though - having a Go runtime in every running process in the host OS feels undesirable to me. > Reviewed-by: Michal Privoznik <mprivozn@redhat.com> 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2019-09-24 at 16:33 +0100, Daniel P. Berrangé wrote: > +<?xml version="1.0" encoding="UTF-8"?> Throughout the document: s/meson/Meson/g s/M4/m4/g > +<!DOCTYPE html> > +<html xmlns="http://www.w3.org/1999/xhtml"> > + <body> > + <h1>Libvirt Project Strategy</h1> s/Libvirt// (it's redundant here). > + > + <p> > + This document attempts to outline the libvirt project strategy for > + the near future. Think of this as a high level vision or todo list s/todo/to-do/ > + <h2>Language consolidation</h2> > + > + <p> > + At time of writing libvirt uses the following languages s/languages/languages:/ > + <dt>Shell</dt> > + <dd>The autoconf configure script, is essentially shell script. The use of "essentially" makes it sound like it's claiming to be something else, which is not the case. I'd rewrite this as <code>configure</code>, generated by autoconf, is a shell script. > + <dt>M4</dt> > + <dd>The autoconf configure script uses a large number of M4 macros to s/configure/<code>configure</code>/ > + <p> > + 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 shell, m4, make, > + automake, awk, sed, perl and python, with debugging requiring s/perl and python/Perl and Python/ > + understanding of the interactions between many languages. The > + relative popularity of the languages has implications for how easily > + the project can attract new contributors, and the quality of the code > + they'll be able to submit. This is most notable when comparing Perl > + to Python, as since the start of the libvirt project, the popularity > + and knowledge of Perl has declined, while Python has risen. This last sentence just sounds weird to me. I would suggest something like ... 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, resulting in a lot of effort being spent to s/, resulting/results/ > + 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. s/was/is/ > + With this in mind the libvirt project has set a vision for language > + usage in the future s/future/future:/ > + <dt>Python</dt> > + <dd>Various supporting build/test scripts are written in Python 3 > + compatible mode only.</dd> s/are written/are to be written/ > + 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 wrt the previous code. s/wrt/with respect to/ > + 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. s/Python, over/Python over/ > + 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 > + https://readthedocs.org/. The ability to embed raw HTML in the RST docs As pointed out by Michal, this should be a clickable link. With nits pointed out above fixed, Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.