On Tue, Apr 03, 2018 at 15:56:11 +0100, Daniel P. Berrangé wrote:
Describe how we decide which host platforms to support for libvirt,
which in turn makes it easier to decide when a platform / software
version can be dropped.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/index.html.in | 2 +-
docs/platforms.html.in | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 docs/platforms.html.in
diff --git a/docs/index.html.in b/docs/index.html.in
index 1b3a7a3db6..4783c39e3c 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -28,7 +28,7 @@
The libvirt project:
</p>
<ul>
- <li>is a toolkit to manage virtualization hosts</li>
+ <li>is a toolkit to manage <a
href="platforms.html.in">virtualization platforms</a></li>
<li>is accessible from C, Python, Perl, Java and more</li>
<li>is licensed under open source licenses</li>
<li>supports <a href="drvqemu.html">KVM</a>,
diff --git a/docs/platforms.html.in b/docs/platforms.html.in
new file mode 100644
index 0000000000..859b482428
--- /dev/null
+++ b/docs/platforms.html.in
@@ -0,0 +1,74 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html
xmlns="http://www.w3.org/1999/xhtml">
+ <body>
+ <h1>Supported host platforms</h1>
+
+ <ul id="toc"></ul>
+
+ <h2>Build targets</h2>
+
+ <p>
+ Libvirt drivers aim to support building and executing on multiple
+ host OS platforms. This document outlines which platforms are the
+ major build targets. These platforms are used as the basis for deciding
+ upon the minimum required versions of 3rd party software libvirt depends
+ on. If a platform is no listed here, it does not imply that libvirt
+ won't work. If an unlisted platform has comparable software versions
+ to a listed platform, there is every expectation that it will work.
+ Bug reports are welcome for problems encountered on unlisted platforms
+ unless they are clearly older vintage that what is described here.
+ </p>
I think we should explicitly mention that we do not support possible
downstream extensions or modifications to any 3rd party software used by
libvirt. In other words, e.g., QEMU 0.12 was HMP-only upstream and thus
libvirt will use HMP to talk to QEMU from RHEL-6 even though QMP support
was backported to the downstream QEMU version. Of course, if a feature
which can be properly detected by libvirt is backported to an earlier
version, libvirt may be able to use it, although I'd still consider it
unsupported in terms "don't file bug reports if it doesn't work, as long
as it works with upstream QEMU".
Jirka