mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-07-11 12:25:52 +00:00
fix typos in docs
docs/formatdomain.html docs/formatdomain.html.in docs/java.html docs/java.html.in
This commit is contained in:
Atsushi SAKAI
parent
f61ac900b7
commit
c11e64efbd
@ -1,3 +1,8 @@
|
||||
Fri Aug 8 19:18:43 JST 2008 Atsushi SAKAI <sakaia@jp.fujitsu.com>
|
||||
|
||||
* docs/formatdomain.html docs/formatdomain.html.in
|
||||
docs/java.html docs/java.html.in: fix typos
|
||||
|
||||
Thu Aug 7 19:47:40 CEST 2008 Daniel Veillard <veillard@redhat.com>
|
||||
|
||||
* tests/domainschematest: patch from Guido Günther to fix RNG checking
|
||||
|
||||
@ -252,10 +252,10 @@
|
||||
(badly named!) refers to an OS that supports the Xen 3 hypervisor
|
||||
guest ABI. There are also two optional attributes, <code>arch</code>
|
||||
specifying the CPU architecture to virtualization, and <code>machine</code>
|
||||
refering to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
|
||||
referring to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
|
||||
provides details on allowed values for these. <span class="since">Since 0.0.1</span></dd><dt><code>loader</code></dt><dd>The optional <code>loader</code> tag refers to a firmware blob
|
||||
used to assist the domain creation process. At this time, it is
|
||||
only needed by Xen fullyvirtualized domains. <span class="since">Since 0.1.0</span></dd><dt><code>boot</code></dt><dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
|
||||
only needed by Xen fully virtualized domains. <span class="since">Since 0.1.0</span></dd><dt><code>boot</code></dt><dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
|
||||
"cdrom" or "network" and is used to specify the next boot device
|
||||
to consider. The <code>boot</code> element can be repeated multiple
|
||||
times to setup a priority list of boot devices to try in turn.
|
||||
@ -267,7 +267,7 @@
|
||||
<p>
|
||||
Hypervisors employing paravirtualization do not usually emulate
|
||||
a BIOS, and instead the host is responsible to kicking off the
|
||||
operating system boot. This may use a pseduo-bootloader in the
|
||||
operating system boot. This may use a pseudo-bootloader in the
|
||||
host to provide an interface to choose a kernel for the guest.
|
||||
An example is <code>pygrub</code> with Xen.
|
||||
</p>
|
||||
@ -277,9 +277,9 @@
|
||||
<bootloader_args>--append single</bootloader_args>
|
||||
...</pre>
|
||||
<dl><dt><code>bootloader</code></dt><dd>The content of the <code>bootloader</code> element provides
|
||||
a fullyqualified path to the bootloader executable in the
|
||||
a fully qualified path to the bootloader executable in the
|
||||
host OS. This bootloader will be run to choose which kernel
|
||||
to boot. The required output of the bootloader is dependant
|
||||
to boot. The required output of the bootloader is dependent
|
||||
on the hypervisor in use. <span class="since">Since 0.1.0</span></dd><dt><code>bootloader_args</code></dt><dd>The optional <code>bootloader_args</code> element allows
|
||||
command line arguments to be passed to the bootloader.
|
||||
<span class="since">Since 0.2.3</span>
|
||||
@ -330,7 +330,7 @@
|
||||
<a name="elementsLifecycle" id="elementsLifecycle">Lifecycle control</a>
|
||||
</h3>
|
||||
<p>
|
||||
It is sometimes neccessary to override the default actions taken
|
||||
It is sometimes necessary to override the default actions taken
|
||||
when a guest OS triggers a lifecycle operation. The following
|
||||
collections of elements allow the actions to be specified. A
|
||||
common use case is to force a reboot to be treated as a poweroff
|
||||
@ -402,7 +402,7 @@
|
||||
<a name="elementsDevices" id="elementsDevices">Devices</a>
|
||||
</h3>
|
||||
<p>
|
||||
The final set of XML elements are all used to descibe devices
|
||||
The final set of XML elements are all used to describe devices
|
||||
provided to the guest domain. All devices occur as children
|
||||
of the main <code>devices</code> element.
|
||||
<span class="since">Since 0.1.3</span>
|
||||
@ -446,7 +446,7 @@
|
||||
<code>type</code> is "block", then the <code>dev</code> attribute specifies
|
||||
the path to the host device to serve as the disk. <span class="since">Since 0.0.3</span></dd><dt><code>target</code></dt><dd>The <code>target</code> element controls the bus / device under which the
|
||||
disk is exposed to the guest OS. The <code>dev</code> attribute indicates
|
||||
the "logical" device name. The actual device name specified is not guarenteed to map to
|
||||
the "logical" device name. The actual device name specified is not guaranteed to map to
|
||||
the device name in the guest OS. Treat it as a device ordering hint.
|
||||
The optional <code>bus</code> attribute specifies the type of disk device
|
||||
to emulate; possible values are driver specific, with typical values being
|
||||
@ -628,7 +628,7 @@
|
||||
...
|
||||
<input type='mouse' bus='usb'/>
|
||||
...</pre>
|
||||
<dl><dt><code>input</code></dt><dd>The <code>input</code> element has one madatory attribute, the <code>type</code>
|
||||
<dl><dt><code>input</code></dt><dd>The <code>input</code> element has one mandatory attribute, the <code>type</code>
|
||||
whose value can be either 'mouse' or 'tablet'. The latter provides absolute
|
||||
cursor movement, while the former uses relative movement. The optional
|
||||
<code>bus</code> attribute can be used to refine the exact device type.
|
||||
@ -760,7 +760,7 @@
|
||||
...</pre>
|
||||
<p>
|
||||
NB special case if <console type='pty'>, then the TTY
|
||||
path is also duplicated as an attribute tty='/dv/pts/3'
|
||||
path is also duplicated as an attribute tty='/dev/pts/3'
|
||||
on the top level <console> tag. This provides compat
|
||||
with existing syntax for <console> tags.
|
||||
</p>
|
||||
@ -771,7 +771,7 @@
|
||||
The character device is passed through to the underlying
|
||||
physical character device. The device types must match,
|
||||
eg the emulated serial port should only be connected to
|
||||
a host serial port - dont connect a serial port to a parallel
|
||||
a host serial port - don't connect a serial port to a parallel
|
||||
port.
|
||||
</p>
|
||||
<pre>
|
||||
|
||||
@ -84,12 +84,12 @@
|
||||
(badly named!) refers to an OS that supports the Xen 3 hypervisor
|
||||
guest ABI. There are also two optional attributes, <code>arch</code>
|
||||
specifying the CPU architecture to virtualization, and <code>machine</code>
|
||||
refering to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
|
||||
referring to the machine type. The <a href="formatcaps.html">Capabilities XML</a>
|
||||
provides details on allowed values for these. <span class="since">Since 0.0.1</span></dd>
|
||||
<dt><code>loader</code></dt>
|
||||
<dd>The optional <code>loader</code> tag refers to a firmware blob
|
||||
used to assist the domain creation process. At this time, it is
|
||||
only needed by Xen fullyvirtualized domains. <span class="since">Since 0.1.0</span></dd>
|
||||
only needed by Xen fully virtualized domains. <span class="since">Since 0.1.0</span></dd>
|
||||
<dt><code>boot</code></dt>
|
||||
<dd>The <code>dev</code> attribute takes one of the values "fd", "hd",
|
||||
"cdrom" or "network" and is used to specify the next boot device
|
||||
@ -104,7 +104,7 @@
|
||||
<p>
|
||||
Hypervisors employing paravirtualization do not usually emulate
|
||||
a BIOS, and instead the host is responsible to kicking off the
|
||||
operating system boot. This may use a pseduo-bootloader in the
|
||||
operating system boot. This may use a pseudo-bootloader in the
|
||||
host to provide an interface to choose a kernel for the guest.
|
||||
An example is <code>pygrub</code> with Xen.
|
||||
</p>
|
||||
@ -118,9 +118,9 @@
|
||||
<dl>
|
||||
<dt><code>bootloader</code></dt>
|
||||
<dd>The content of the <code>bootloader</code> element provides
|
||||
a fullyqualified path to the bootloader executable in the
|
||||
a fully qualified path to the bootloader executable in the
|
||||
host OS. This bootloader will be run to choose which kernel
|
||||
to boot. The required output of the bootloader is dependant
|
||||
to boot. The required output of the bootloader is dependent
|
||||
on the hypervisor in use. <span class="since">Since 0.1.0</span></dd>
|
||||
<dt><code>bootloader_args</code></dt>
|
||||
<dd>The optional <code>bootloader_args</code> element allows
|
||||
@ -196,7 +196,7 @@
|
||||
<h3><a name="elementsLifecycle">Lifecycle control</a></h3>
|
||||
|
||||
<p>
|
||||
It is sometimes neccessary to override the default actions taken
|
||||
It is sometimes necessary to override the default actions taken
|
||||
when a guest OS triggers a lifecycle operation. The following
|
||||
collections of elements allow the actions to be specified. A
|
||||
common use case is to force a reboot to be treated as a poweroff
|
||||
@ -301,7 +301,7 @@
|
||||
<h3><a name="elementsDevices">Devices</a></h3>
|
||||
|
||||
<p>
|
||||
The final set of XML elements are all used to descibe devices
|
||||
The final set of XML elements are all used to describe devices
|
||||
provided to the guest domain. All devices occur as children
|
||||
of the main <code>devices</code> element.
|
||||
<span class="since">Since 0.1.3</span>
|
||||
@ -358,7 +358,7 @@
|
||||
<dt><code>target</code></dt>
|
||||
<dd>The <code>target</code> element controls the bus / device under which the
|
||||
disk is exposed to the guest OS. The <code>dev</code> attribute indicates
|
||||
the "logical" device name. The actual device name specified is not guarenteed to map to
|
||||
the "logical" device name. The actual device name specified is not guaranteed to map to
|
||||
the device name in the guest OS. Treat it as a device ordering hint.
|
||||
The optional <code>bus</code> attribute specifies the type of disk device
|
||||
to emulate; possible values are driver specific, with typical values being
|
||||
@ -557,7 +557,7 @@
|
||||
|
||||
<dl>
|
||||
<dt><code>input</code></dt>
|
||||
<dd>The <code>input</code> element has one madatory attribute, the <code>type</code>
|
||||
<dd>The <code>input</code> element has one mandatory attribute, the <code>type</code>
|
||||
whose value can be either 'mouse' or 'tablet'. The latter provides absolute
|
||||
cursor movement, while the former uses relative movement. The optional
|
||||
<code>bus</code> attribute can be used to refine the exact device type.
|
||||
@ -716,7 +716,7 @@
|
||||
|
||||
<p>
|
||||
NB special case if <console type='pty'>, then the TTY
|
||||
path is also duplicated as an attribute tty='/dv/pts/3'
|
||||
path is also duplicated as an attribute tty='/dev/pts/3'
|
||||
on the top level <console> tag. This provides compat
|
||||
with existing syntax for <console> tags.
|
||||
</p>
|
||||
@ -727,7 +727,7 @@
|
||||
The character device is passed through to the underlying
|
||||
physical character device. The device types must match,
|
||||
eg the emulated serial port should only be connected to
|
||||
a host serial port - dont connect a serial port to a parallel
|
||||
a host serial port - don't connect a serial port to a parallel
|
||||
port.
|
||||
</p>
|
||||
|
||||
|
||||
@ -105,7 +105,7 @@
|
||||
<h2>Presentation</h2>
|
||||
<p>The Java bindings are currently a work in progress based mostly
|
||||
on the work of Toth Istvan. The first usable release is 0.2.0, where
|
||||
most of the naming conventions were defined. Futher release will try
|
||||
most of the naming conventions were defined. Further release will try
|
||||
as much as possible to stay compatible</p>
|
||||
<h2>Getting it</h2>
|
||||
<p>
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
<h2>Presentation</h2>
|
||||
<p>The Java bindings are currently a work in progress based mostly
|
||||
on the work of Toth Istvan. The first usable release is 0.2.0, where
|
||||
most of the naming conventions were defined. Futher release will try
|
||||
most of the naming conventions were defined. Further release will try
|
||||
as much as possible to stay compatible</p>
|
||||
|
||||
<h2>Getting it</h2>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user