[libvirt PATCH 5/9] docs: html.in: Convert architecture to rst

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx>
---
 docs/architecture.html.in | 82 --------------------------------------
 docs/architecture.rst     | 83 +++++++++++++++++++++++++++++++++++++++
 docs/meson.build          |  2 +-
 3 files changed, 84 insertions(+), 83 deletions(-)
 delete mode 100644 docs/architecture.html.in
 create mode 100644 docs/architecture.rst

diff --git a/docs/architecture.html.in b/docs/architecture.html.in
deleted file mode 100644
index 7a5cf2dca8..0000000000
--- a/docs/architecture.html.in
+++ /dev/null
@@ -1,82 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE html>
-<html xmlns="http://www.w3.org/1999/xhtml";>
-  <body>
-    <h1 >libvirt architecture</h1>
-
-    <p>
-      Currently libvirt supports 2 kind of virtualization, and its
-      internal structure is based on a driver model which simplifies
-      adding new
-      engines:
-    </p>
-
-    <ul id="toc"></ul>
-
-    <h2><a id="Xen">Xen support</a></h2>
-
-    <p>When running in a Xen environment, programs using libvirt have to execute
-in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
-kernel provides most if not all of the actual drivers used by the set of
-domains. It also runs the Xen Store, a database of information shared by the
-hypervisor, the backend drivers, any running domains, and libxl (aka libxenlight).
-libxl provides a set of APIs for creating and managing domains, which can be used
-by applications such as the xl tool provided by Xen or libvirt. The hypervisor,
-drivers, kernels and daemons communicate though a shared system bus
-implemented in the hypervisor. The figure below tries to provide a view of
-this environment:</p>
-    <img src="architecture.gif" alt="The Xen architecture" />
-    <p>The library will interact with libxl for all management operations
-on a Xen system.</p>
-    <p>Note that the libvirt libxl driver only supports root access.</p>
-
-    <h2><a id="QEMU">QEMU and KVM support</a></h2>
-
-    <p>The model for QEMU and KVM is completely similar, basically KVM is based
-on QEMU for the process controlling a new domain, only small details differs
-between the two. In both case the libvirt API is provided by a controlling
-process forked by libvirt in the background and which launch and control the
-QEMU or KVM process. That program called libvirt_qemud talks though a specific
-protocol to the library, and connects to the console of the QEMU process in
-order to control and report on its status. Libvirt tries to expose all the
-emulations models of QEMU, the selection is done when creating the new
-domain, by specifying the architecture and machine type targeted.</p>
-    <p>The code controlling the QEMU process is available in the
-<code>qemud/</code> directory.</p>
-
-    <h2><a id="drivers">Driver based architecture</a></h2>
-
-    <p>As the previous section explains, libvirt can communicate using different
-channels with the current hypervisor, and should also be able to use
-different kind of hypervisor. To simplify the internal design, code, ease
-maintenance and simplify the support of other virtualization engine the
-internals have been structured as one core component, the libvirt.c module
-acting as a front-end for the library API and a set of hypervisor drivers
-defining a common set of routines. That way the Xen Daemon access, the Xen
-Store one, the Hypervisor hypercall are all isolated in separate C modules
-implementing at least a subset of the common operations defined by the
-drivers present in driver.h:</p>
-    <ul>
-      <li>xend_internal: implements the driver functions though the Xen
-  Daemon</li>
-      <li>xs_internal: implements the subset of the driver available though the
-    Xen Store</li>
-      <li>xen_internal: provide the implementation of the functions possible via
-    direct hypervisor access</li>
-      <li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
-    is in the <code>proxy/</code> directory.</li>
-      <li>xm_internal: provide support for Xen defined but not running
-    domains.</li>
-      <li>qemu_internal: implement the driver functions for QEMU and
-    KVM virtualization engines. It also uses a qemud/ specific daemon
-    which interacts with the QEMU process to implement libvirt API.</li>
-      <li>test: this is a test driver useful for regression tests of the
-    front-end part of libvirt.</li>
-    </ul>
-    <p>Note that a given driver may only implement a subset of those functions,
-(for example saving a Xen domain state to disk and restoring it is only
-possible though the Xen Daemon), in that case the driver entry points for
-unsupported functions are initialized to NULL.</p>
-    <p></p>
-  </body>
-</html>
diff --git a/docs/architecture.rst b/docs/architecture.rst
new file mode 100644
index 0000000000..f74906d36e
--- /dev/null
+++ b/docs/architecture.rst
@@ -0,0 +1,83 @@
+====================
+libvirt architecture
+====================
+
+Currently libvirt supports 2 kind of virtualization, and its internal
+structure is based on a driver model which simplifies adding new
+engines:
+
+.. contents::
+
+Xen support
+-----------
+
+When running in a Xen environment, programs using libvirt have to
+execute in "Domain 0", which is the primary Linux OS loaded on the
+machine. That OS kernel provides most if not all of the actual drivers
+used by the set of domains. It also runs the Xen Store, a database of
+information shared by the hypervisor, the backend drivers, any running
+domains, and libxl (aka libxenlight). libxl provides a set of APIs for
+creating and managing domains, which can be used by applications such as
+the xl tool provided by Xen or libvirt. The hypervisor, drivers, kernels
+and daemons communicate though a shared system bus implemented in the
+hypervisor. The figure below tries to provide a view of this
+environment:
+
+|The Xen architecture|
+
+The library will interact with libxl for all management operations on a
+Xen system.
+
+Note that the libvirt libxl driver only supports root access.
+
+QEMU and KVM support
+--------------------
+
+The model for QEMU and KVM is completely similar, basically KVM is based
+on QEMU for the process controlling a new domain, only small details
+differs between the two. In both case the libvirt API is provided by a
+controlling process forked by libvirt in the background and which launch
+and control the QEMU or KVM process. That program called libvirt_qemud
+talks though a specific protocol to the library, and connects to the
+console of the QEMU process in order to control and report on its
+status. Libvirt tries to expose all the emulations models of QEMU, the
+selection is done when creating the new domain, by specifying the
+architecture and machine type targeted.
+
+The code controlling the QEMU process is available in the ``qemud/``
+directory.
+
+Driver based architecture
+-------------------------
+
+As the previous section explains, libvirt can communicate using
+different channels with the current hypervisor, and should also be able
+to use different kind of hypervisor. To simplify the internal design,
+code, ease maintenance and simplify the support of other virtualization
+engine the internals have been structured as one core component, the
+libvirt.c module acting as a front-end for the library API and a set of
+hypervisor drivers defining a common set of routines. That way the Xen
+Daemon access, the Xen Store one, the Hypervisor hypercall are all
+isolated in separate C modules implementing at least a subset of the
+common operations defined by the drivers present in driver.h:
+
+-  xend_internal: implements the driver functions though the Xen Daemon
+-  xs_internal: implements the subset of the driver available though the
+   Xen Store
+-  xen_internal: provide the implementation of the functions possible
+   via direct hypervisor access
+-  proxy_internal: provide read-only Xen access via a proxy, the proxy
+   code is in the ``proxy/`` directory.
+-  xm_internal: provide support for Xen defined but not running domains.
+-  qemu_internal: implement the driver functions for QEMU and KVM
+   virtualization engines. It also uses a qemud/ specific daemon which
+   interacts with the QEMU process to implement libvirt API.
+-  test: this is a test driver useful for regression tests of the
+   front-end part of libvirt.
+
+Note that a given driver may only implement a subset of those functions,
+(for example saving a Xen domain state to disk and restoring it is only
+possible though the Xen Daemon), in that case the driver entry points
+for unsupported functions are initialized to NULL.
+
+.. |The Xen architecture| image:: architecture.gif
diff --git a/docs/meson.build b/docs/meson.build
index b61377ea8b..0e0c266cb9 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -32,7 +32,6 @@ docs_assets = [
 
 docs_html_in_files = [
   '404',
-  'architecture',
   'auditlog',
   'auth',
   'bindings',
@@ -107,6 +106,7 @@ docs_rst_files = [
   'api_extension',
   'api',
   'apps',
+  'architecture',
   'best-practices',
   'ci',
   'coding-style',
-- 
2.29.2




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux