diff --git a/docs/api_extension.html.in b/docs/api_extension.html.in index de6eedc877f2622296151e3d5163c8d94b4fc2fd..6a99cd98ddcce60ed3fb752f7259339d881f93c7 100644 --- a/docs/api_extension.html.in +++ b/docs/api_extension.html.in @@ -10,8 +10,13 @@
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. + API in libvirt. It uses as an example the addition of an API for + separating maximum from current vcpu usage of a domain. + Remember that new API consists of any new public functions, as + well as the addition of flags or extensions of XML used by + existing functions. The example in this document adds both new + functions and an XML extension. Not all libvirt API additions + require quite as many patches.
@@ -23,7 +28,12 @@ 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. + don't wait too long before getting feedback. In the vcpu example + below, list feedback was first requested + here + and resulted in several rounds of improvements before coding + began. In turn, this example is slightly rearranged from the actual + order of the commits.
@@ -46,11 +56,22 @@
@@ -66,11 +87,10 @@ 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. + don't drop a big blob of code on the mailing list in one go. + Also, you should follow the upstream tree, and rebase your + series to adapt your patches to work with any other changes + that were accepted upstream during your development.
@@ -86,9 +106,24 @@
The first task is to define the public API and add it to:
+The first task is to define the public API. If the new API + involves an XML extension, you have to enhance the RelaxNG + schema and document the new elements or attributes:
-include/libvirt/libvirt.h.in
+ docs/schemas/domain.rng
+ docs/formatdomain.html.in
+
If the API extension involves a new function, you have to add a + declaration in the public header, and arrange to export the + function name (symbol) so other programs can link against the + libvirt library and call the new function:
+ +
+ include/libvirt/libvirt.h.in
+ src/libvirt_public.syms
+
This task is in many ways the most important to get right, since once @@ -99,12 +134,9 @@ rework it as you go through the process of implementing it.
-Once you have defined the API, you have to add the symbol names to:
- -src/libvirt_public.syms
See 0001-Step-1-of-8-Define-the-public-API.patch for example code.
- +See 0001-Step-1-of-15-add-to-xml.patch + and 0002-Step-2-of-15-add-new-public-API.patch + for example code.
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 + an entirely new driver type, in which case the changes will include the creation of a new struct type to represent the new driver type.
@@ -129,10 +161,11 @@
To define the internal API, first typedef the driver function
prototype and then add a new field for it to the relevant driver
- struct.
+ struct. Then, update all existing instances of the driver to
+ provide a NULL
stub for the new function.
See 0002-Step-2-of-8-Define-the-internal-driver-API.patch
+See 0003-Step-3-of-15-define-internal-driver-API.patch
src/libvirt.c
See 0003-Step-3-of-8-Implement-the-public-API.patch
+See 0004-Step-4-of-15-implement-the-public-APIs.patch
+ ++ Implementing the remote protocol is essentially a + straightforward exercise which is probably most easily + understood by referring to the existing code and the example + patch. It involves several related changes, including the + regeneration of derived files, with further details below. +
+See 0005-Step-5-of-15-implement-the-remote-protocol.patch
-- 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: + Defining the wire protocol involves making additions to:
src/remote/remote_protocol.x
See 0004-Step-4-of-8-Define-the-wire-protocol-format.patch
-Once these changes are in place, it's necessary to run 'make rpcgen' in the src 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 + results in bogus compile time warnings. This regenerates the + following files:
+
+ daemon/remote_dispatch_args.h
+ daemon/remote_dispatch_prototypes.h
+ daemon/remote_dispatch_table.h
+ src/remote/remote_protocol.c
+ src/remote/remote_protocol.h
+
- 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: + Implementing the uses the rpcgen generated .h files. The remote + method calls go in:
src/remote/remote_internal.c
- Once you have created the remote method calls, you have to add fields - for them to the driver structs for the appropriate remote driver. -
- -See 0005-Step-5-of-8-Implement-the-RPC-client.patch
- -- Implementing the server side of the remote function calls is simply a + Implementing the server side of the remote function call 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: @@ -247,8 +286,64 @@
Again, this step uses the .h files generated by make rpcgen.
-See 0006-Step-6-of-8-Implement-the-server-side-dispatcher.patch
++ After all three pieces of the remote protocol are complete, and + the generated files have been updated, it will be necessary to + update the file:
+ +src/remote_protocol-structs
+ This file should only have new lines added; modifications to + existing lines probably imply a backwards-incompatible API change. +
+ +See 0005-Step-5-of-15-implement-the-remote-protocol.patch
+ ++ Sometimes, a new API serves as a superset of existing API, by + adding more granularity in what can be managed. When this is + the case, it makes sense to share a common implementation by + making the older API become a trivial wrapper around the new + API, rather than duplicating the common code. This step should + not introduce any semantic differences for the old API, and is + not necessary if the new API has no relation to existing API. +
+ +See 0006-Step-6-of-15-make-old-API-trivially-wrap-to-new-API.patch
+ ++ All new API should be manageable from the virsh command line + shell. This proves that the API is sufficient for the intended + purpose, and helps to identify whether the proposed API needs + slight changes for easier usage. However, remember that virsh + is used to connect to hosts running older versions of libvirtd, + so new commands should have fallbacks to an older API if + possible; implementing the virsh hooks at this point makes it + very easy to test these fallbacks. Also remember to document + virsh additions. +
+ ++ 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 in place you can write the function + implementing the virsh command. Finally, you need to add the new + command to the commands[] array. The following files need changes: +
+ +
+ tools/virsh.c
+ tools/virsh.pod
+
See 0007-Step-7-of-15-add-virsh-support.patch
- 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. + If the new API is applicable to more than one driver, it may + make sense to provide some utility routines, or to factor some + of the work into the dispatcher, to avoid reimplementing the + same code in every driver. In the example code, this involved + adding a member to the virDomainDefPtr struct for mapping + between the XML API addition and the in-memory representation of + a domain, along with updating all clients to use the new member. + Up to this point, there have been no changes to existing + semantics, and the new APIs will fail unless they are used in + the same way as the older API wrappers.
+See 0008-Step-8-of-15-support-new-xml.patch
+ +- 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. + The remaining patches should only touch one driver at a time. + It is possible to implement all changes for a driver in one + patch, but for review purposes it may still make sense to break + things into simpler steps. Here is where the new APIs finally + start working.
-See 0007-Step-7-of-8-Implement-the-driver-methods.patch
++ In the example patches, three separate drivers are supported: + test, qemu, and xen. It is always a good idea to patch the test + driver in addition to the target driver, to prove that the API + can be used for more than one driver. The example updates the + test driver in one patch: +
-See 0009-Step-9-of-15-support-all-flags-in-test-driver.patch
- 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. + The qemu changes were easier to split into two phases, one for + updating the mapping between the new XML and the hypervisor + command line arguments, and one for supporting all possible + flags of the new API:
+See 0010-Step-10-of-15-improve-vcpu-support-in-qemu-command-line.patch + and 0011-Step-11-of-15-complete-vcpu-support-in-qemu-driver.patch
+- 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. + Finally, the example breaks the xen driver changes across four + patches. One maps the XML changes to the hypervisor command, + the next two are independently implementing the getter and + setter APIs, and the last one provides cleanup of code that was + rendered dead by the new API.
-See 0008-Step-8-of-8-Add-virsh-support.patch
+See 0012-Step-12-of-15-improve-vcpu-support-in-xen-command-line.patch, + 0013-Step-13-of-15-improve-support-for-getting-xen-vcpu-counts.patch, + 0014-Step-14-of-15-improve-support-for-setting-xen-vcpu-counts.patch, + and 0015-Step-15-of-15-remove-dead-xen-code.patch
+ ++ The exact details of the example code are probably uninteresting + unless you're concerned with virtual cpu management. +
-Once you have working functionality, run make check and make - syntax-check before generating patches.
++ Once you have working functionality, run make check and make + syntax-check on each patch of the series before submitting + patches. It may also be worth writing tests for the libvirt-TCK + testsuite to exercise your new API, although those patches are + not kept in the libvirt repository. +