From c11e64efbd896461561eec86ad583535eee046ff Mon Sep 17 00:00:00 2001 From: Atsushi SAKAI Date: Fri, 8 Aug 2008 10:24:14 +0000 Subject: [PATCH] fix typos in docs docs/formatdomain.html docs/formatdomain.html.in docs/java.html docs/java.html.in --- ChangeLog | 5 +++++ docs/formatdomain.html | 22 +++++++++++----------- docs/formatdomain.html.in | 22 +++++++++++----------- docs/java.html | 2 +- docs/java.html.in | 2 +- 5 files changed, 29 insertions(+), 24 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6854042c98..e392765a65 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +Fri Aug 8 19:18:43 JST 2008 Atsushi SAKAI + + * 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 * tests/domainschematest: patch from Guido Günther to fix RNG checking diff --git a/docs/formatdomain.html b/docs/formatdomain.html index 5e615d5e80..346f96085f 100644 --- a/docs/formatdomain.html +++ b/docs/formatdomain.html @@ -252,10 +252,10 @@ (badly named!) refers to an OS that supports the Xen 3 hypervisor guest ABI. There are also two optional attributes, arch specifying the CPU architecture to virtualization, and machine - refering to the machine type. The Capabilities XML + referring to the machine type. The Capabilities XML provides details on allowed values for these. Since 0.0.1
loader
The optional loader tag refers to a firmware blob used to assist the domain creation process. At this time, it is - only needed by Xen fullyvirtualized domains. Since 0.1.0
boot
The dev attribute takes one of the values "fd", "hd", + only needed by Xen fully virtualized domains. Since 0.1.0
boot
The dev attribute takes one of the values "fd", "hd", "cdrom" or "network" and is used to specify the next boot device to consider. The boot element can be repeated multiple times to setup a priority list of boot devices to try in turn. @@ -267,7 +267,7 @@

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 pygrub with Xen.

@@ -277,9 +277,9 @@ <bootloader_args>--append single</bootloader_args> ...
bootloader
The content of the bootloader 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. Since 0.1.0
bootloader_args
The optional bootloader_args element allows command line arguments to be passed to the bootloader. Since 0.2.3 @@ -330,7 +330,7 @@ Lifecycle control

- 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 @@ Devices

- 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 devices element. Since 0.1.3 @@ -446,7 +446,7 @@ type is "block", then the dev attribute specifies the path to the host device to serve as the disk. Since 0.0.3

target
The target element controls the bus / device under which the disk is exposed to the guest OS. The dev 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 bus 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'/> ... -
input
The input element has one madatory attribute, the type +
input
The input element has one mandatory attribute, the type whose value can be either 'mouse' or 'tablet'. The latter provides absolute cursor movement, while the former uses relative movement. The optional bus attribute can be used to refine the exact device type. @@ -760,7 +760,7 @@ ...

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.

@@ -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. 

diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index cc6473fea2..d4f650e6e1 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -84,12 +84,12 @@
 	(badly named!) refers to an OS that supports the Xen 3 hypervisor
 	guest ABI. There are also two optional attributes, arch
 	specifying the CPU architecture to virtualization, and machine
-	refering to the machine type. The Capabilities XML
+	referring to the machine type. The Capabilities XML
 	provides details on allowed values for these. Since 0.0.1
loader
The optional loader tag refers to a firmware blob used to assist the domain creation process. At this time, it is - only needed by Xen fullyvirtualized domains. Since 0.1.0
+ only needed by Xen fully virtualized domains. Since 0.1.0
boot
The dev attribute takes one of the values "fd", "hd", "cdrom" or "network" and is used to specify the next boot device @@ -104,7 +104,7 @@

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 pygrub with Xen.

@@ -118,9 +118,9 @@
bootloader
The content of the bootloader 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. Since 0.1.0
bootloader_args
The optional bootloader_args element allows @@ -196,7 +196,7 @@

Lifecycle control

- 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 @@

Devices

- 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 devices element. Since 0.1.3 @@ -358,7 +358,7 @@

target
The target element controls the bus / device under which the disk is exposed to the guest OS. The dev 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 bus attribute specifies the type of disk device to emulate; possible values are driver specific, with typical values being @@ -557,7 +557,7 @@
input
-
The input element has one madatory attribute, the type +
The input element has one mandatory attribute, the type whose value can be either 'mouse' or 'tablet'. The latter provides absolute cursor movement, while the former uses relative movement. The optional bus attribute can be used to refine the exact device type. @@ -716,7 +716,7 @@

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.

@@ -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.

diff --git a/docs/java.html b/docs/java.html index 2b0c15f20a..572e583193 100644 --- a/docs/java.html +++ b/docs/java.html @@ -105,7 +105,7 @@

Presentation

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

Getting it

diff --git a/docs/java.html.in b/docs/java.html.in index 316070cf35..2d9a24fa12 100644 --- a/docs/java.html.in +++ b/docs/java.html.in @@ -6,7 +6,7 @@

Presentation

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

Getting it

-- 2.47.2