External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 21:55:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Added docs on extending public API (Dave Allen)

Browse Source
This commit is contained in:
Daniel P. Berrange 2009-06-09 11:42:41 +00:00
parent f969e393a9
commit ce958c191c
50 changed files with 2666 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
ChangeLog
View File

@ -1,3 +1,12 @@
Tue Jun 9 12:39:24 BST 2009 Daniel P. Berrange <berrange@redhat.com>
API extension docs (Dave Allen)
* docs/internals.html.in, docs/api_extension.html.in,
docs/sitemap.html.in: Start new section on libvirt internal
development & add doc about public API extensions
* docs/api_extension/*patch: Example patch files
* docs/*.html: Re-generate for updated sitemap
Thu Jun 4 15:54:24 CEST 2009 Daniel Veillard <veillard@redhat.com>
* src/xm_internals.c: the memory shrinking on device removal

3
docs/Makefile.am
View File

@ -46,6 +46,8 @@ gif = \
dot_html_in = $(wildcard *.html.in)
dot_html = $(dot_html_in:%.html.in=%.html)
patches = $(wildcard api_extension/*.patch)
xml = \
libvirt-api.xml \
libvirt-refs.xml \
@ -67,6 +69,7 @@ EXTRA_DIST= \
site.xsl newapi.xsl news.xsl page.xsl ChangeLog.xsl \
$(dot_html) $(dot_html_in) $(gif) $(apihtml) $(apipng) \
$(xml) $(fig) $(png) \
$(patches) \
virsh.pod ChangeLog.awk
all: web $(top_builddir)/NEWS $(man_MANS)

4
docs/api.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

361
docs/api_extension.html Normal file
View File

@ -0,0 +1,361 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!--
This file is autogenerated from api_extension.html.in
Do not edit this file. Changes will be lost.
-->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="SHORTCUT ICON" href="32favicon.png" />
<title>libvirt: Implementing a new API in Libvirt</title>
<meta name="description" content="libvirt, virtualization, virtualization API" />
</head>
<body>
<div id="header">
<div id="headerLogo"></div>
<div id="headerSearch">
<form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
<input id="query" name="query" type="text" size="12" value="" />
<input id="submit" name="submit" type="submit" value="Search" />
</div></form>
</div>
</div>
<div id="body">
<div id="menu">
<ul class="l0"><li>
<div>
<a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
</div>
</li><li>
<div>
<a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
</div>
</li><li>
<div>
<a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
</div>
</li><li>
<div>
<a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
<ul class="l1"><li>
<div>
<a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
</div>
</li><li>
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="inactive" href="intro.html">Architecture</a>
</div>
</li><li>
<div>
<a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
</div>
</li><li>
<div>
<a title="Hypervisor specific driver information" class="inactive" href="drivers.html">Drivers</a>
</div>
</li><li>
<div>
<a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
</div>
</li><li>
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="active" href="internals.html">Internals</a>
<ul class="l2"><li>
<div>
<span class="active">API extensions</span>
</div>
</li></ul>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
</div>
</li><li>
<div>
<a title="Frequently asked questions" class="inactive" href="FAQ.html">FAQ</a>
</div>
</li><li>
<div>
<a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
</div>
</li><li>
<div>
<a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
</div>
</li><li>
<div>
<a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
</div>
</li><li>
<div>
<a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
</div>
</li></ul>
</div>
<div id="content">
<h1>Implementing a new API in Libvirt</h1>
<ul><li>
<a href="#publicapi">Defining the public API</a>
</li><li>
<a href="#internalapi">Defining the internal API</a>
</li><li>
<a href="#implpublic">Implementing the public API</a>
</li><li>
<a href="#wireproto">Defining the wire protocol format</a>
</li><li>
<a href="#rpcclient">Implement the RPC client</a>
</li><li>
<a href="#serverdispatch">Implement the server side dispatcher</a>
</li><li>
<a href="#driverimpl">Implement the driver methods</a>
</li><li>
<a href="#virsh">Implement virsh commands</a>
</li></ul>
<p>
This document walks you through the process of implementing a new
API in libvirt. It uses as an example the addition of the node device
create and destroy APIs.
</p>
<p>
Before you begin coding, it is critical that you propose your
changes on the libvirt mailing list and get feedback on your ideas to
make sure what you're proposing fits with the general direction of the
project. Even before doing a proof of concept implementation, send an
email giving an overview of the functionality you think should be
added to libvirt. Someone may already be working on the feature you
want. Also, recognize that everything you write is likely to undergo
significant rework as you discuss it with the other developers, so
don't wait too long before getting feedback.
</p>
<p>
Adding a new API to libvirt is not difficult, but there are quite a
few steps. This document assumes that you are familiar with C
programming and have checked out the libvirt code from the source code
repository and successfully built the existing tree. Instructions on
how to check out and build the code can be found at:
</p>
<p>
<a href="http://libvirt.org/downloads.html">http://libvirt.org/downloads.html</a>
</p>
<p>
Once you have a working development environment, the steps to create a
new API are:
</p>
<ol><li>define the public API</li><li>define the internal driver API</li><li>implement the public API</li><li>define the wire protocol format</li><li>implement the RPC client</li><li>implement the server side dispatcher</li><li>implement the driver methods</li><li>add virsh support</li></ol>
<p>
It is, of course, possible to implement the pieces in any order, but
if the development tasks are completed in the order listed, the code
will compile after each step. Given the number of changes required,
verification after each step is highly recommended.
</p>
<p>
Submit new code in the form shown in the example code: one patch
per step. That's not to say submit patches before you have working
functionality--get the whole thing working and make sure you're happy
with it. Then use git or some other version control system that lets
you rewrite your commit history and break patches into pieces so you
don't drop a big blob of code on the mailing list at one go. For
example, I didn't follow my own advice when I originally submitted the
example code to the libvirt list but rather submitted it in several
large chunks. I've used git's ability to rewrite my commit history to
break the code apart into the example patches shown.
</p>
<p>
Don't mix anything else into the patches you submit. The patches
should be the minimal changes required to implement the functionality
you're adding. If you notice a bug in unrelated code (i.e., code you
don't have to touch to implement your API change) during development,
create a patch that just addresses that bug and submit it
separately.
</p>
<p>With that said, let's begin.</p>
<h2>
<a name="publicapi" id="publicapi">Defining the public API</a>
</h2>
<p>The first task is to define the public API and add it to:</p>
<p>
<code>include/libvirt/libvirt.h.in</code>
</p>
<p>
This task is in many ways the most important to get right, since once
the API has been committed to the repository, it's libvirt's policy
never to change it. Mistakes in the implementation are bugs that you
can fix. Make a mistake in the API definition and you're stuck with
it, so think carefully about the interface and don't be afraid to
rework it as you go through the process of implementing it.
</p>
<p>Once you have defined the API, you have to add the symbol names to:</p>
<p>
<code>src/libvirt_public.syms</code>
</p>
<p class="example">See <a href="api_extension/0001-Step-1-of-8-Define-the-public-API.patch">0001-Step-1-of-8-Define-the-public-API.patch</a> for example code.</p>
<h2>
<a name="internalapi" id="internalapi">Defining the internal API</a>
</h2>
<p>
Each public API call is associated with a driver, such as a host
virtualization driver, a network virtualization driver, a storage
virtualization driver, a state driver, or a device monitor. Adding
the internal API is ordinarily a matter of adding a new member to the
struct representing one of these drivers.
</p>
<p>
Of course, it's possible that the new API will involve the creation of
an entire new driver type, in which case the changes will include the
creation of a new struct type to represent the new driver type.
</p>
<p>The driver structs are defined in:</p>
<p>
<code>src/driver.h</code>
</p>
<p>
To define the internal API, first typedef the driver function
prototype and then add a new field for it to the relevant driver
struct.
</p>
<p class="example">See <a href="api_extension/0002-Step-2-of-8-Define-the-internal-driver-API.patch">0002-Step-2-of-8-Define-the-internal-driver-API.patch</a></p>
<h2>
<a name="implpublic" id="implpublic">Implementing the public API</a>
</h2>
<p>
Implementing the public API is largely a formality in which we wire up
public API to the internal driver API. The public API implementation
takes care of some basic validity checks before passing control to the
driver implementation. In RFC 2119 vocabulary, this function:
</p>
<ol class="ordinarylist"><li>SHOULD log a message with VIR_DEBUG() indicating that it is
being called and its parameters;</li><li>MUST call virResetLastError();</li><li>SHOULD confirm that the connection is valid with
VIR_IS_CONNECT(conn);</li><li><strong>SECURITY: If the API requires a connection with write
privileges, MUST confirm that the connection flags do not
indicate that the connection is read-only;</strong></li><li>SHOULD do basic validation of the parameters that are being
passed in;</li><li>MUST confirm that the driver for this connection exists and that
it implements this function;</li><li>MUST call the internal API;</li><li>SHOULD log a message with VIR_DEBUG() indicating that it is
returning, its return value, and status.</li><li>MUST return status to the caller.</li></ol>
<p>The public API calls are implemented in:</p>
<p>
<code>src/libvirt.c</code>
</p>
<p class="example">See <a href="api_extension/0003-Step-3-of-8-Implement-the-public-API.patch">0003-Step-3-of-8-Implement-the-public-API.patch</a></p>
<h2>
<a name="wireproto" id="wireproto">Defining the wire protocol format</a>
</h2>
<p>
Defining the wire protocol is essentially a straightforward exercise
which is probably most easily understood by referring to the existing
remote protocol wire format definitions and the example patch. It
involves making two additions to:
</p>
<p>
<code>qemud/remote_protocol.x</code>
</p>
<p>
First, create two new structs for each new function that you're adding
to the API. One struct describes the parameters to be passed to the
remote function, and a second struct describes the value returned by
the remote function. The one exception to this rule is that functions
that return only integer status do not require a struct for returned
data.
</p>
<p>
Second, add values to the remote_procedure enum for each new function
added to the API.
</p>
<p class="example">See <a href="api_extension/0004-Step-4-of-8-Define-the-wire-protocol-format.patch">0004-Step-4-of-8-Define-the-wire-protocol-format.patch</a></p>
<p>
Once these changes are in place, it's necessary to run 'make rpcgen'
in the qemud directory to create the .c and .h files required by the
remote protocol code. This must be done on a Linux host using the
GLibC rpcgen program. Other rpcgen versions may generate code which
results in bogus compile time warnings
</p>
<h2>
<a name="rpcclient" id="rpcclient">Implement the RPC client</a>
</h2>
<p>
Implementing the RPC client is also relatively mechanical, so refer to
the exising code and example patch for guidance. The RPC client uses
the rpcgen generated .h files. The remote method calls go in:
</p>
<p>
<code>src/remote_internal.c</code>
</p>
<p>Each remote method invocation does the following:</p>
<ol class="ordinarylist"><li>locks the remote driver;</li><li>sets up the method arguments;</li><li>invokes the remote function;</li><li>checks the return value, if necessary;</li><li>extracts any returned data;</li><li>frees any returned data;</li><li>unlocks the remote driver.</li></ol>
<p>
Once you have created the remote method calls, you have to add fields
for them to the driver structs for the appropriate remote driver.
</p>
<p class="example">See <a href="api_extension/0005-Step-5-of-8-Implement-the-RPC-client.patch">0005-Step-5-of-8-Implement-the-RPC-client.patch</a></p>
<h2>
<a name="serverdispatch" id="serverdispatch">Implement the server side dispatcher</a>
</h2>
<p>
Implementing the server side of the remote function calls is simply a
matter of deserializing the parameters passed in from the remote
caller and passing them to the corresponding internal API function.
The server side dispatchers are implemented in:
</p>
<p>
<code>qemud/remote.c</code>
</p>
<p>Again, this step uses the .h files generated by make rpcgen.</p>
<p class="example">See <a href="api_extension/0006-Step-6-of-8-Implement-the-server-side-dispatcher.patch">0006-Step-6-of-8-Implement-the-server-side-dispatcher.patch</a></p>
<h2>
<a name="driverimpl" id="driverimpl">Implement the driver methods</a>
</h2>
<p>
So, after all that, we get to the fun part. All functionality in
libvirt is implemented inside a driver. Thus, here is where you
implement whatever functionality you're adding to libvirt. You'll
either need to add additional files to the src directory or extend
files that are already there, depending on what functionality you're
adding.
</p>
<p>
In the example code, the extension is only an additional two function
calls in the node device API, so most of the new code is additions to
existing files. The only new files are there for multi-platform
implementation convenience, as some of the new code is Linux specific.
</p>
<p>
The example code is probably uninteresting unless you're concerned
with libvirt storage, but I've included it here to show how new files
are added to the build environment.
</p>
<p class="example">See <a href="api_extension/0007-Step-7-of-8-Implement-the-driver-methods.patch">0007-Step-7-of-8-Implement-the-driver-methods.patch</a></p>
<h2>
<a name="virsh" id="virsh">Implement virsh commands</a>
</h2>
<p>
Once you have the new functionality in place, the easiest way to test
it and also to provide it to end users is to implement support for it
in virsh.
</p>
<p>
A virsh command is composed of a few pieces of code. You need to
define an array of vshCmdInfo structs for each new command that
contain the help text and the command description text. You also need
an array of vshCmdOptDef structs to describe the command options.
Once you have those pieces of data in place you can write the function
implementing the virsh command. Finally, you need to add the new
command to the commands[] array.
</p>
<p class="example">See <a href="api_extension/0008-Step-8-of-8-Add-virsh-support.patch">0008-Step-8-of-8-Add-virsh-support.patch</a></p>
<p>Once you have working functionality, run make check and make
syntax-check before generating patches.</p>
</div>
</div>
<div id="footer">
<p id="sponsor">
Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
</div>
</body>
</html>

302
docs/api_extension.html.in Normal file
View File

@ -0,0 +1,302 @@
<html>
<head>
<title>Implementing a new API in Libvirt</title>
</head>
<body>
<h1>Implementing a new API in Libvirt</h1>
<ul id="toc"></ul>
<p>
This document walks you through the process of implementing a new
API in libvirt. It uses as an example the addition of the node device
create and destroy APIs.
</p>
<p>
Before you begin coding, it is critical that you propose your
changes on the libvirt mailing list and get feedback on your ideas to
make sure what you're proposing fits with the general direction of the
project. Even before doing a proof of concept implementation, send an
email giving an overview of the functionality you think should be
added to libvirt. Someone may already be working on the feature you
want. Also, recognize that everything you write is likely to undergo
significant rework as you discuss it with the other developers, so
don't wait too long before getting feedback.
</p>
<p>
Adding a new API to libvirt is not difficult, but there are quite a
few steps. This document assumes that you are familiar with C
programming and have checked out the libvirt code from the source code
repository and successfully built the existing tree. Instructions on
how to check out and build the code can be found at:
</p>
<p>
<a href="http://libvirt.org/downloads.html">http://libvirt.org/downloads.html</a>
</p>
<p>
Once you have a working development environment, the steps to create a
new API are:
</p>
<ol>
<li>define the public API</li>
<li>define the internal driver API</li>
<li>implement the public API</li>
<li>define the wire protocol format</li>
<li>implement the RPC client</li>
<li>implement the server side dispatcher</li>
<li>implement the driver methods</li>
<li>add virsh support</li>
</ol>
<p>
It is, of course, possible to implement the pieces in any order, but
if the development tasks are completed in the order listed, the code
will compile after each step. Given the number of changes required,
verification after each step is highly recommended.
</p>
<p>
Submit new code in the form shown in the example code: one patch
per step. That's not to say submit patches before you have working
functionality--get the whole thing working and make sure you're happy
with it. Then use git or some other version control system that lets
you rewrite your commit history and break patches into pieces so you
don't drop a big blob of code on the mailing list at one go. For
example, I didn't follow my own advice when I originally submitted the
example code to the libvirt list but rather submitted it in several
large chunks. I've used git's ability to rewrite my commit history to
break the code apart into the example patches shown.
</p>
<p>
Don't mix anything else into the patches you submit. The patches
should be the minimal changes required to implement the functionality
you're adding. If you notice a bug in unrelated code (i.e., code you
don't have to touch to implement your API change) during development,
create a patch that just addresses that bug and submit it
separately.
</p>
<p>With that said, let's begin.</p>
<h2><a name='publicapi'>Defining the public API</a></h2>
<p>The first task is to define the public API and add it to:</p>
<p><code>include/libvirt/libvirt.h.in</code></p>
<p>
This task is in many ways the most important to get right, since once
the API has been committed to the repository, it's libvirt's policy
never to change it. Mistakes in the implementation are bugs that you
can fix. Make a mistake in the API definition and you're stuck with
it, so think carefully about the interface and don't be afraid to
rework it as you go through the process of implementing it.
</p>
<p>Once you have defined the API, you have to add the symbol names to:</p>
<p><code>src/libvirt_public.syms</code></p>
<p class="example">See <a href="api_extension/0001-Step-1-of-8-Define-the-public-API.patch">0001-Step-1-of-8-Define-the-public-API.patch</a> for example code.</p>
<h2><a name='internalapi'>Defining the internal API</a></h2>
<p>
Each public API call is associated with a driver, such as a host
virtualization driver, a network virtualization driver, a storage
virtualization driver, a state driver, or a device monitor. Adding
the internal API is ordinarily a matter of adding a new member to the
struct representing one of these drivers.
</p>
<p>
Of course, it's possible that the new API will involve the creation of
an entire new driver type, in which case the changes will include the
creation of a new struct type to represent the new driver type.
</p>
<p>The driver structs are defined in:</p>
<p><code>src/driver.h</code></p>
<p>
To define the internal API, first typedef the driver function
prototype and then add a new field for it to the relevant driver
struct.
</p>
<p class="example">See <a href="api_extension/0002-Step-2-of-8-Define-the-internal-driver-API.patch">0002-Step-2-of-8-Define-the-internal-driver-API.patch</a></p>
<h2><a name='implpublic'>Implementing the public API</a></h2>
<p>
Implementing the public API is largely a formality in which we wire up
public API to the internal driver API. The public API implementation
takes care of some basic validity checks before passing control to the
driver implementation. In RFC 2119 vocabulary, this function:
</p>
<ol class="ordinarylist">
<li>SHOULD log a message with VIR_DEBUG() indicating that it is
being called and its parameters;</li>
<li>MUST call virResetLastError();</li>
<li>SHOULD confirm that the connection is valid with
VIR_IS_CONNECT(conn);</li>
<li><strong>SECURITY: If the API requires a connection with write
privileges, MUST confirm that the connection flags do not
indicate that the connection is read-only;</strong></li>
<li>SHOULD do basic validation of the parameters that are being
passed in;</li>
<li>MUST confirm that the driver for this connection exists and that
it implements this function;</li>
<li>MUST call the internal API;</li>
<li>SHOULD log a message with VIR_DEBUG() indicating that it is
returning, its return value, and status.</li>
<li>MUST return status to the caller.</li>
</ol>
<p>The public API calls are implemented in:</p>
<p><code>src/libvirt.c</code></p>
<p class="example">See <a href="api_extension/0003-Step-3-of-8-Implement-the-public-API.patch">0003-Step-3-of-8-Implement-the-public-API.patch</a></p>
<h2><a name='wireproto'>Defining the wire protocol format</a></h2>
<p>
Defining the wire protocol is essentially a straightforward exercise
which is probably most easily understood by referring to the existing
remote protocol wire format definitions and the example patch. It
involves making two additions to:
</p>
<p><code>qemud/remote_protocol.x</code></p>
<p>
First, create two new structs for each new function that you're adding
to the API. One struct describes the parameters to be passed to the
remote function, and a second struct describes the value returned by
the remote function. The one exception to this rule is that functions
that return only integer status do not require a struct for returned
data.
</p>
<p>
Second, add values to the remote_procedure enum for each new function
added to the API.
</p>
<p class="example">See <a href="api_extension/0004-Step-4-of-8-Define-the-wire-protocol-format.patch">0004-Step-4-of-8-Define-the-wire-protocol-format.patch</a></p>
<p>
Once these changes are in place, it's necessary to run 'make rpcgen'
in the qemud directory to create the .c and .h files required by the
remote protocol code. This must be done on a Linux host using the
GLibC rpcgen program. Other rpcgen versions may generate code which
results in bogus compile time warnings
</p>
<h2><a name='rpcclient'>Implement the RPC client</a></h2>
<p>
Implementing the RPC client is also relatively mechanical, so refer to
the exising code and example patch for guidance. The RPC client uses
the rpcgen generated .h files. The remote method calls go in:
</p>
<p><code>src/remote_internal.c</code></p>
<p>Each remote method invocation does the following:</p>
<ol class="ordinarylist">
<li>locks the remote driver;</li>
<li>sets up the method arguments;</li>
<li>invokes the remote function;</li>
<li>checks the return value, if necessary;</li>
<li>extracts any returned data;</li>
<li>frees any returned data;</li>
<li>unlocks the remote driver.</li>
</ol>
<p>
Once you have created the remote method calls, you have to add fields
for them to the driver structs for the appropriate remote driver.
</p>
<p class="example">See <a href="api_extension/0005-Step-5-of-8-Implement-the-RPC-client.patch">0005-Step-5-of-8-Implement-the-RPC-client.patch</a></p>
<h2><a name="serverdispatch">Implement the server side dispatcher</a></h2>
<p>
Implementing the server side of the remote function calls is simply a
matter of deserializing the parameters passed in from the remote
caller and passing them to the corresponding internal API function.
The server side dispatchers are implemented in:
</p>
<p><code>qemud/remote.c</code></p>
<p>Again, this step uses the .h files generated by make rpcgen.</p>
<p class="example">See <a href="api_extension/0006-Step-6-of-8-Implement-the-server-side-dispatcher.patch">0006-Step-6-of-8-Implement-the-server-side-dispatcher.patch</a></p>
<h2><a name="driverimpl">Implement the driver methods</a></h2>
<p>
So, after all that, we get to the fun part. All functionality in
libvirt is implemented inside a driver. Thus, here is where you
implement whatever functionality you're adding to libvirt. You'll
either need to add additional files to the src directory or extend
files that are already there, depending on what functionality you're
adding.
</p>
<p>
In the example code, the extension is only an additional two function
calls in the node device API, so most of the new code is additions to
existing files. The only new files are there for multi-platform
implementation convenience, as some of the new code is Linux specific.
</p>
<p>
The example code is probably uninteresting unless you're concerned
with libvirt storage, but I've included it here to show how new files
are added to the build environment.
</p>
<p class="example">See <a href="api_extension/0007-Step-7-of-8-Implement-the-driver-methods.patch">0007-Step-7-of-8-Implement-the-driver-methods.patch</a></p>
<h2><a name="virsh">Implement virsh commands</a></h2>
<p>
Once you have the new functionality in place, the easiest way to test
it and also to provide it to end users is to implement support for it
in virsh.
</p>
<p>
A virsh command is composed of a few pieces of code. You need to
define an array of vshCmdInfo structs for each new command that
contain the help text and the command description text. You also need
an array of vshCmdOptDef structs to describe the command options.
Once you have those pieces of data in place you can write the function
implementing the virsh command. Finally, you need to add the new
command to the commands[] array.
</p>
<p class="example">See <a href="api_extension/0008-Step-8-of-8-Add-virsh-support.patch">0008-Step-8-of-8-Add-virsh-support.patch</a></p>
<p>Once you have working functionality, run make check and make
syntax-check before generating patches.</p>
</body>
</html>

45
docs/api_extension/0001-Step-1-of-8-Define-the-public-API.patch Normal file
View File

@ -0,0 +1,45 @@
From 2ae8fd62a1e5e085b7902da9bc207b806d84fd91 Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Tue, 19 May 2009 16:16:11 -0400
Subject: [PATCH] Step 1 of 8 Define the public API
---
include/libvirt/libvirt.h.in | 6 ++++++
src/libvirt_public.syms | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index a028b21..2f7076f 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -1124,6 +1124,12 @@ int virNodeDeviceDettach (virNodeDevicePtr dev);
int virNodeDeviceReAttach (virNodeDevicePtr dev);
int virNodeDeviceReset (virNodeDevicePtr dev);
+virNodeDevicePtr virNodeDeviceCreateXML (virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags);
+
+int virNodeDeviceDestroy (virNodeDevicePtr dev);
+
/*
* Domain Event Notification
*/
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index f7ebbc3..b8f9128 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -258,4 +258,10 @@ LIBVIRT_0.6.1 {
virNodeGetSecurityModel;
} LIBVIRT_0.6.0;
+LIBVIRT_0.6.3 {
+ global:
+ virNodeDeviceCreateXML;
+ virNodeDeviceDestroy;
+} LIBVIRT_0.6.1;
+
# .... define new API here using predicted next version number ....
--
1.6.0.6

37
docs/api_extension/0002-Step-2-of-8-Define-the-internal-driver-API.patch Normal file
View File

@ -0,0 +1,37 @@
From b26d7fc2d64e7e6e4d3ea2b43361015d3620d7a6 Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Tue, 19 May 2009 16:19:14 -0400
Subject: [PATCH] Step 2 of 8 Define the internal driver API
---
src/driver.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/driver.h b/src/driver.h
index 39dc413..c357b76 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -684,6 +684,11 @@ typedef int (*virDevMonDeviceListCaps)(virNodeDevicePtr dev,
char **const names,
int maxnames);
+typedef virNodeDevicePtr (*virDrvNodeDeviceCreateXML)(virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags);
+typedef int (*virDrvNodeDeviceDestroy)(virNodeDevicePtr dev);
+
/**
* _virDeviceMonitor:
*
@@ -702,6 +707,8 @@ struct _virDeviceMonitor {
virDevMonDeviceGetParent deviceGetParent;
virDevMonDeviceNumOfCaps deviceNumOfCaps;
virDevMonDeviceListCaps deviceListCaps;
+ virDrvNodeDeviceCreateXML deviceCreateXML;
+ virDrvNodeDeviceDestroy deviceDestroy;
};
/*
--
1.6.0.6

120
docs/api_extension/0003-Step-3-of-8-Implement-the-public-API.patch Normal file
View File

@ -0,0 +1,120 @@
From fc585594a207dfb9149e7d3d01c9eb1c79b6d52d Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Tue, 19 May 2009 16:22:23 -0400
Subject: [PATCH] Step 3 of 8 Implement the public API
---
src/libvirt.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index f3d4484..ded18a7 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -7509,6 +7509,103 @@ error:
}
+/**
+ * virNodeDeviceCreateXML:
+ * @conn: pointer to the hypervisor connection
+ * @xmlDesc: string containing an XML description of the device to be created
+ * @flags: callers should always pass 0
+ *
+ * Create a new device on the VM host machine, for example, virtual
+ * HBAs created using vport_create.
+ *
+ * Returns a node device object if successful, NULL in case of failure
+ */
+virNodeDevicePtr
+virNodeDeviceCreateXML(virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags)
+{
+ VIR_DEBUG("conn=%p, xmlDesc=%s, flags=%d", conn, xmlDesc, flags);
+
+ virResetLastError();
+
+ if (!VIR_IS_CONNECT(conn)) {
+ virLibConnError(NULL, VIR_ERR_INVALID_CONN, __FUNCTION__);
+ return NULL;
+ }
+
+ if (conn->flags & VIR_CONNECT_RO) {
+ virLibConnError(conn, VIR_ERR_OPERATION_DENIED, __FUNCTION__);
+ goto error;
+ }
+
+ if (xmlDesc == NULL) {
+ virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
+ goto error;
+ }
+
+ if (conn->deviceMonitor &&
+ conn->deviceMonitor->deviceCreateXML) {
+ virNodeDevicePtr dev = conn->deviceMonitor->deviceCreateXML(conn, xmlDesc, flags);
+ if (dev == NULL)
+ goto error;
+ return dev;
+ }
+
+ virLibConnError (conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+ /* Copy to connection error object for back compatability */
+ virSetConnError(conn);
+ return NULL;
+}
+
+
+/**
+ * virNodeDeviceDestroy:
+ * @dev: a device object
+ *
+ * Destroy the device object. The virtual device is removed from the host operating system.
+ * This function may require privileged access
+ *
+ * Returns 0 in case of success and -1 in case of failure.
+ */
+int
+virNodeDeviceDestroy(virNodeDevicePtr dev)
+{
+ DEBUG("dev=%p", dev);
+
+ virResetLastError();
+
+ if (!VIR_IS_CONNECTED_NODE_DEVICE(dev)) {
+ virLibNodeDeviceError(NULL, VIR_ERR_INVALID_NODE_DEVICE, __FUNCTION__);
+ return (-1);
+ }
+
+ if (dev->conn->flags & VIR_CONNECT_RO) {
+ virLibConnError(dev->conn, VIR_ERR_OPERATION_DENIED, __FUNCTION__);
+ goto error;
+ }
+
+ if (dev->conn->deviceMonitor &&
+ dev->conn->deviceMonitor->deviceDestroy) {
+ int retval = dev->conn->deviceMonitor->deviceDestroy(dev);
+ if (retval < 0) {
+ goto error;
+ }
+
+ return 0;
+ }
+
+ virLibConnError (dev->conn, VIR_ERR_NO_SUPPORT, __FUNCTION__);
+
+error:
+ /* Copy to connection error object for back compatability */
+ virSetConnError(dev->conn);
+ return -1;
+}
+
+
/*
* Domain Event Notification
*/
--
1.6.0.6

48
docs/api_extension/0004-Step-4-of-8-Define-the-wire-protocol-format.patch Normal file
View File

@ -0,0 +1,48 @@
From bce8f1243b0454c0d70e3db832a039d22faab09a Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Wed, 20 May 2009 13:58:58 -0400
Subject: [PATCH] Step 4 of 8 Define the wire protocol format
---
qemud/remote_protocol.x | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/qemud/remote_protocol.x b/qemud/remote_protocol.x
index 2d8e6a2..2c79949 100644
--- a/qemud/remote_protocol.x
+++ b/qemud/remote_protocol.x
@@ -1109,6 +1109,19 @@ struct remote_node_device_reset_args {
remote_nonnull_string name;
};
+struct remote_node_device_create_xml_args {
+ remote_nonnull_string xml_desc;
+ int flags;
+};
+
+struct remote_node_device_create_xml_ret {
+ remote_nonnull_node_device dev;
+};
+
+struct remote_node_device_destroy_args {
+ remote_nonnull_string name;
+};
+
/**
* Events Register/Deregister:
@@ -1270,7 +1283,10 @@ enum remote_procedure {
REMOTE_PROC_NODE_DEVICE_RESET = 120,
REMOTE_PROC_DOMAIN_GET_SECURITY_LABEL = 121,
- REMOTE_PROC_NODE_GET_SECURITY_MODEL = 122
+ REMOTE_PROC_NODE_GET_SECURITY_MODEL = 122,
+
+ REMOTE_PROC_NODE_DEVICE_CREATE_XML = 123,
+ REMOTE_PROC_NODE_DEVICE_DESTROY = 124
};
/* Custom RPC structure. */
--
1.6.0.6

85
docs/api_extension/0005-Step-5-of-8-Implement-the-RPC-client.patch Normal file
View File

@ -0,0 +1,85 @@
From ff272552c297966ace3492aefe91fc830152251a Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Tue, 19 May 2009 16:26:12 -0400
Subject: [PATCH] Step 5 of 8 Implement the RPC client
---
src/remote_internal.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/src/remote_internal.c b/src/remote_internal.c
index 4b3afb0..e665ef8 100644
--- a/src/remote_internal.c
+++ b/src/remote_internal.c
@@ -4978,6 +4978,59 @@ done:
}
+static virNodeDevicePtr
+remoteNodeDeviceCreateXML(virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags)
+{
+ remote_node_device_create_xml_args args;
+ remote_node_device_create_xml_ret ret;
+ virNodeDevicePtr dev = NULL;
+ struct private_data *priv = conn->privateData;
+
+ remoteDriverLock(priv);
+
+ memset(&ret, 0, sizeof ret);
+ args.xml_desc = (char *)xmlDesc;
+ args.flags = flags;
+
+ if (call(conn, priv, 0, REMOTE_PROC_NODE_DEVICE_CREATE_XML,
+ (xdrproc_t) xdr_remote_node_device_create_xml_args, (char *) &args,
+ (xdrproc_t) xdr_remote_node_device_create_xml_ret, (char *) &ret) == -1)
+ goto done;
+
+ dev = get_nonnull_node_device(conn, ret.dev);
+ xdr_free ((xdrproc_t) xdr_remote_node_device_create_xml_ret, (char *) &ret);
+
+done:
+ remoteDriverUnlock(priv);
+ return dev;
+}
+
+static int
+remoteNodeDeviceDestroy(virNodeDevicePtr dev)
+{
+ int rv = -1;
+ remote_node_device_destroy_args args;
+ struct private_data *priv = dev->conn->privateData;
+
+ remoteDriverLock(priv);
+
+ args.name = dev->name;
+
+ if (call(dev->conn, priv, 0, REMOTE_PROC_NODE_DEVICE_DESTROY,
+ (xdrproc_t) xdr_remote_node_device_destroy_args, (char *) &args,
+ (xdrproc_t) xdr_void, (char *) NULL) == -1)
+ goto done;
+
+ rv = 0;
+
+done:
+ remoteDriverUnlock(priv);
+ return rv;
+}
+
+
/*----------------------------------------------------------------------*/
static int
@@ -6982,6 +7035,8 @@ static virDeviceMonitor dev_monitor = {
.deviceGetParent = remoteNodeDeviceGetParent,
.deviceNumOfCaps = remoteNodeDeviceNumOfCaps,
.deviceListCaps = remoteNodeDeviceListCaps,
+ .deviceCreateXML = remoteNodeDeviceCreateXML,
+ .deviceDestroy = remoteNodeDeviceDestroy
};
--
1.6.0.6

71
docs/api_extension/0006-Step-6-of-8-Implement-the-server-side-dispatcher.patch Normal file
View File

@ -0,0 +1,71 @@
From 4c5166df583459574526841234d61d6ae5be19a0 Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Tue, 19 May 2009 16:26:55 -0400
Subject: [PATCH] Step 6 of 8 Implement the server side dispatcher
---
qemud/remote.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/qemud/remote.c b/qemud/remote.c
index e27820f..8d24a3a 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -4323,6 +4323,54 @@ remoteDispatchNodeDeviceReset (struct qemud_server *server ATTRIBUTE_UNUSED,
}
+static int
+remoteDispatchNodeDeviceCreateXml(struct qemud_server *server ATTRIBUTE_UNUSED,
+ struct qemud_client *client ATTRIBUTE_UNUSED,
+ virConnectPtr conn,
+ remote_error *rerr,
+ remote_node_device_create_xml_args *args,
+ remote_node_device_create_xml_ret *ret)
+{
+ virNodeDevicePtr dev;
+
+ dev = virNodeDeviceCreateXML (conn, args->xml_desc, args->flags);
+ if (dev == NULL) {
+ remoteDispatchConnError(rerr, conn);
+ return -1;
+ }
+
+ make_nonnull_node_device (&ret->dev, dev);
+ virNodeDeviceFree(dev);
+
+ return 0;
+}
+
+
+static int
+remoteDispatchNodeDeviceDestroy(struct qemud_server *server ATTRIBUTE_UNUSED,
+ struct qemud_client *client ATTRIBUTE_UNUSED,
+ virConnectPtr conn,
+ remote_error *rerr,
+ remote_node_device_destroy_args *args,
+ void *ret ATTRIBUTE_UNUSED)
+{
+ virNodeDevicePtr dev;
+
+ dev = virNodeDeviceLookupByName(conn, args->name);
+ if (dev == NULL) {
+ remoteDispatchFormatError(rerr, "%s", _("node_device not found"));
+ return -1;
+ }
+
+ if (virNodeDeviceDestroy(dev) == -1) {
+ remoteDispatchConnError(rerr, conn);
+ return -1;
+ }
+
+ return 0;
+}
+
+
/**************************
* Async Events
**************************/
--
1.6.0.6

1172
docs/api_extension/0007-Step-7-of-8-Implement-the-driver-methods.patch Normal file
View File

File diff suppressed because it is too large Load Diff

133
docs/api_extension/0008-Step-8-of-8-Add-virsh-support.patch Normal file
View File

@ -0,0 +1,133 @@
From 193cc4abbb6c2fc5557d3699f86ff0103d5a21ef Mon Sep 17 00:00:00 2001
From: David Allan <dallan@redhat.com>
Date: Tue, 19 May 2009 16:47:31 -0400
Subject: [PATCH 8/8] Step 8 of 8 Add virsh support
---
src/virsh.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/src/virsh.c b/src/virsh.c
index cb32ede..ab2a2b7 100644
--- a/src/virsh.c
+++ b/src/virsh.c
@@ -2962,6 +2962,107 @@ cmdPoolCreate(vshControl *ctl, const vshCmd *cmd)
/*
+ * "nodedev-create" command
+ */
+static const vshCmdInfo info_node_device_create[] = {
+ {"help", gettext_noop("create a device defined "
+ "by an XML file on the node")},
+ {"desc", gettext_noop("Create a device on the node. Note that this "
+ "command creates devices on the physical host "
+ "that can then be assigned to a virtual machine.")},
+ {NULL, NULL}
+};
+
+static const vshCmdOptDef opts_node_device_create[] = {
+ {"file", VSH_OT_DATA, VSH_OFLAG_REQ,
+ gettext_noop("file containing an XML description of the device")},
+ {NULL, 0, 0, NULL}
+};
+
+static int
+cmdNodeDeviceCreate(vshControl *ctl, const vshCmd *cmd)
+{
+ virNodeDevicePtr dev = NULL;
+ char *from;
+ int found = 0;
+ int ret = TRUE;
+ char *buffer;
+
+ if (!vshConnectionUsability(ctl, ctl->conn, TRUE))
+ return FALSE;
+
+ from = vshCommandOptString(cmd, "file", &found);
+ if (!found) {
+ return FALSE;
+ }
+
+ if (virFileReadAll(from, VIRSH_MAX_XML_FILE, &buffer) < 0) {
+ return FALSE;
+ }
+
+ dev = virNodeDeviceCreateXML(ctl->conn, buffer, 0);
+ free (buffer);
+
+ if (dev != NULL) {
+ vshPrint(ctl, _("Node device %s created from %s\n"),
+ virNodeDeviceGetName(dev), from);
+ } else {
+ vshError(ctl, FALSE, _("Failed to create node device from %s"), from);
+ ret = FALSE;
+ }
+
+ return ret;
+}
+
+
+/*
+ * "nodedev-destroy" command
+ */
+static const vshCmdInfo info_node_device_destroy[] = {
+ {"help", gettext_noop("destroy a device on the node")},
+ {"desc", gettext_noop("Destroy a device on the node. Note that this "
+ "command destroys devices on the physical host ")},
+ {NULL, NULL}
+};
+
+static const vshCmdOptDef opts_node_device_destroy[] = {
+ {"name", VSH_OT_DATA, VSH_OFLAG_REQ,
+ gettext_noop("name of the device to be destroyed")},
+ {NULL, 0, 0, NULL}
+};
+
+static int
+cmdNodeDeviceDestroy(vshControl *ctl, const vshCmd *cmd)
+{
+ virNodeDevicePtr dev = NULL;
+ int ret = TRUE;
+ int found = 0;
+ char *name;
+
+ if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) {
+ return FALSE;
+ }
+
+ name = vshCommandOptString(cmd, "name", &found);
+ if (!found) {
+ return FALSE;
+ }
+
+ dev = virNodeDeviceLookupByName(ctl->conn, name);
+
+ if (virNodeDeviceDestroy(dev) == 0) {
+ vshPrint(ctl, _("Destroyed node device '%s'\n"), name);
+ } else {
+ vshError(ctl, FALSE, _("Failed to destroy node device '%s'"), name);
+ ret = FALSE;
+ }
+
+ virNodeDeviceFree(dev);
+ return ret;
+}
+
+
+/*
* XML Building helper for pool-define-as and pool-create-as
*/
static const vshCmdOptDef opts_pool_X_as[] = {
@@ -5895,6 +5996,8 @@ static const vshCmdDef commands[] = {
{"nodedev-dettach", cmdNodeDeviceDettach, opts_node_device_dettach, info_node_device_dettach},
{"nodedev-reattach", cmdNodeDeviceReAttach, opts_node_device_reattach, info_node_device_reattach},
{"nodedev-reset", cmdNodeDeviceReset, opts_node_device_reset, info_node_device_reset},
+ {"nodedev-create", cmdNodeDeviceCreate, opts_node_device_create, info_node_device_create},
+ {"nodedev-destroy", cmdNodeDeviceDestroy, opts_node_device_destroy, info_node_device_destroy},
{"pool-autostart", cmdPoolAutostart, opts_pool_autostart, info_pool_autostart},
{"pool-build", cmdPoolBuild, opts_pool_build, info_pool_build},
--
1.6.0.6

4
docs/archdomain.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/archnetwork.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/archnode.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/archstorage.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/auth.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/bindings.html
View File

@ -72,6 +72,10 @@
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/deployment.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/docs.html
View File

@ -63,6 +63,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drivers.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvlxc.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvopenvz.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvqemu.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvremote.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvtest.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvuml.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvvbox.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/drvxen.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/format.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/formatcaps.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/formatdomain.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/formatnetwork.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/formatnode.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/formatstorage.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/goals.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/hvsupport.html
View File

@ -76,6 +76,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

117
docs/internals.html Normal file
View File

@ -0,0 +1,117 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!--
This file is autogenerated from internals.html.in
Do not edit this file. Changes will be lost.
-->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="SHORTCUT ICON" href="32favicon.png" />
<title>libvirt: libvirt internals</title>
<meta name="description" content="libvirt, virtualization, virtualization API" />
</head>
<body>
<div id="header">
<div id="headerLogo"></div>
<div id="headerSearch">
<form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
<input id="query" name="query" type="text" size="12" value="" />
<input id="submit" name="submit" type="submit" value="Search" />
</div></form>
</div>
</div>
<div id="body">
<div id="menu">
<ul class="l0"><li>
<div>
<a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
</div>
</li><li>
<div>
<a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
</div>
</li><li>
<div>
<a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
</div>
</li><li>
<div>
<a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
<ul class="l1"><li>
<div>
<a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
</div>
</li><li>
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="inactive" href="intro.html">Architecture</a>
</div>
</li><li>
<div>
<a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
</div>
</li><li>
<div>
<a title="Hypervisor specific driver information" class="inactive" href="drivers.html">Drivers</a>
</div>
</li><li>
<div>
<a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
</div>
</li><li>
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<span class="active">Internals</span>
<ul class="l2"><li>
<div>
<a title="Adding new public libvirt APIs" class="inactive" href="api_extension.html">API extensions</a>
</div>
</li></ul>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
</div>
</li><li>
<div>
<a title="Frequently asked questions" class="inactive" href="FAQ.html">FAQ</a>
</div>
</li><li>
<div>
<a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
</div>
</li><li>
<div>
<a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
</div>
</li><li>
<div>
<a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
</div>
</li><li>
<div>
<a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
</div>
</li></ul>
</div>
<div id="content">
<h1>libvirt internals</h1>
<p>
This section provides documents useful to those working on the libvirt
internals, adding new public APIs, new hypervisor drivers or extending
the libvirtd daemon code.
</p>
</div>
</div>
<div id="footer">
<p id="sponsor">
Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
</div>
</body>
</html>

11
docs/internals.html.in Normal file
View File

@ -0,0 +1,11 @@
<html>
<body>
<h1>libvirt internals</h1>
<p>
This section provides documents useful to those working on the libvirt
internals, adding new public APIs, new hypervisor drivers or extending
the libvirtd daemon code.
</p>
</body>
</html>

4
docs/intro.html
View File

@ -88,6 +88,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/java.html
View File

@ -72,6 +72,10 @@
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/logging.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/python.html
View File

@ -72,6 +72,10 @@
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/remote.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

6
docs/sitemap.html
View File

@ -220,6 +220,12 @@
</li><li>
<a href="java.html">Java</a>
<span>overview of the Java API bindings</span>
</li></ul></li><li>
<a href="internals.html">Internals</a>
<span>Working on the internals of libvirt API, driver and daemon code</span>
<ul><li>
<a href="api_extension.html">API extensions</a>
<span>Adding new public libvirt APIs</span>
</li></ul></li></ul></li><li>
<a href="http://wiki.libvirt.org">Wiki</a>
<span>User contributed content</span>

10
docs/sitemap.html.in
View File

@ -210,6 +210,16 @@
</li>
</ul>
</li>
<li>
<a href="internals.html">Internals</a>
<span>Working on the internals of libvirt API, driver and daemon code</span>
<ul>
<li>
<a href="api_extension.html">API extensions</a>
<span>Adding new public libvirt APIs</span>
</li>
</ul>
</li>
</ul>
</li>
<li>

4
docs/storage.html
View File

@ -100,6 +100,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/uri.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>

4
docs/windows.html
View File

@ -84,6 +84,10 @@
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li></ul>
</div>
</li><li>