Index: java.html =================================================================== RCS file: /data/cvs/libvirt/docs/java.html,v retrieving revision 1.1 diff -u -r1.1 java.html --- java.html 22 Jul 2008 17:49:53 -0000 1.1 +++ java.html 7 Aug 2008 06:41:10 -0000 @@ -105,7 +105,7 @@
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
Index: java.html.in =================================================================== RCS file: /data/cvs/libvirt/docs/java.html.in,v retrieving revision 1.1 diff -u -r1.1 java.html.in --- java.html.in 22 Jul 2008 17:49:53 -0000 1.1 +++ java.html.in 7 Aug 2008 06:41:10 -0000 @@ -6,7 +6,7 @@
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
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
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.0boot
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.
bootloader
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.0bootloader_args
bootloader_args
element allows
@@ -196,7 +196,7 @@
- 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 @@
- 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
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
input
element has one madatory attribute, the type
+ 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. Index: formatdomain.html =================================================================== RCS file: /data/cvs/libvirt/docs/formatdomain.html,v retrieving revision 1.10 diff -u -r1.10 formatdomain.html --- formatdomain.html 6 Aug 2008 11:37:54 -0000 1.10 +++ formatdomain.html 7 Aug 2008 06:41:11 -0000 @@ -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.1loader
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.0boot
dev
attribute takes one of the values "fd", "hd",
+ only needed by Xen fully virtualized domains. Since 0.1.0boot
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.
bootloader
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.0bootloader_args
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
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
input
element has one madatory attribute, the type
+ input
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.