ia64/xen-unstable

changeset 15904:a00cc97b392a

docs: Fix typos.
Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>
author kfraser@localhost.localdomain
date Wed Sep 12 09:43:33 2007 +0100 (2007-09-12)
parents fec8b52b1a7f
children 45dbef0ab7a6
files docs/src/interface.tex docs/src/user.tex
line diff
     1.1 --- a/docs/src/interface.tex	Tue Sep 11 19:11:02 2007 +0100
     1.2 +++ b/docs/src/interface.tex	Wed Sep 12 09:43:33 2007 +0100
     1.3 @@ -1052,7 +1052,7 @@ This path contains:
     1.4        \end{description}
     1.5      \end{description}
     1.6  
     1.7 -  \item[vtpm/] a directory containin vtpm backends
     1.8 +  \item[vtpm/] a directory containing vtpm backends
     1.9      \begin{description}
    1.10      \item[$<$domid$>$/] a directory containing vtpm's for domid
    1.11        \begin{description}
    1.12 @@ -1287,7 +1287,7 @@ ring.
    1.13  \subsection{Network ring interface}
    1.14  
    1.15  The network device uses two shared memory rings for communication: one
    1.16 -for transmit, one for receieve.
    1.17 +for transmit, one for receive.
    1.18  
    1.19  Transmit requests are described by the following structure:
    1.20  
    1.21 @@ -1466,7 +1466,7 @@ The fields are as follows:
    1.22    interface
    1.23  \item[id] this value is echoed in the response message for this IO;
    1.24    the guest may use it to identify the original request
    1.25 -\item[sector\_number] start sector on the virtal device for this
    1.26 +\item[sector\_number] start sector on the virtual device for this
    1.27    request
    1.28  \item[frame\_and\_sects] This array contains structures encoding
    1.29    scatter-gather IO to be performed:
    1.30 @@ -1483,7 +1483,7 @@ The fields are as follows:
    1.31  
    1.32  Virtual TPM (VTPM) support provides TPM functionality to each virtual
    1.33  machine that requests this functionality in its configuration file.
    1.34 -The interface enables domains to access therr own private TPM like it
    1.35 +The interface enables domains to access their own private TPM like it
    1.36  was a hardware TPM built into the machine.
    1.37  
    1.38  The virtual TPM interface is implemented as a split driver,
    1.39 @@ -1504,11 +1504,11 @@ the backend can map the pages into its m
    1.40  table mechanism.
    1.41  
    1.42  The backend driver has been implemented to only accept well-formed
    1.43 -TPM requests. To meet this requirement, the length inidicator in the
    1.44 +TPM requests. To meet this requirement, the length indicator in the
    1.45  TPM request must correctly indicate the length of the request.
    1.46  Otherwise an error message is automatically sent back by the device driver.
    1.47  
    1.48 -The virtual TPM implementation listenes for TPM request on /dev/vtpm. Since
    1.49 +The virtual TPM implementation listens for TPM request on /dev/vtpm. Since
    1.50  it must be able to apply the TPM request packet to the virtual TPM instance
    1.51  associated with the virtual machine, a 4-byte virtual TPM instance
    1.52  identifier is prepended to each packet by the backend driver (in network
    1.53 @@ -1536,7 +1536,7 @@ typedef struct {
    1.54  The fields are as follows:
    1.55  
    1.56  \begin{description}
    1.57 -\item[addr] The machine address of the page asscoiated with the TPM
    1.58 +\item[addr] The machine address of the page associated with the TPM
    1.59              request/response; a request/response may span multiple
    1.60              pages
    1.61  \item[ref]  The grant table reference associated with the address.
    1.62 @@ -1982,7 +1982,7 @@ the value of {\bf op}).  The available o
    1.63    stored.
    1.64  \item[XENMEM\_current\_reservation] Returns current memory reservation
    1.65    of the specified domain.
    1.66 -\item[XENMEM\_maximum\_reservation] Returns maximum memory resrevation
    1.67 +\item[XENMEM\_maximum\_reservation] Returns maximum memory reservation
    1.68    of the specified domain.
    1.69  \end{description}
    1.70  
     2.1 --- a/docs/src/user.tex	Tue Sep 11 19:11:02 2007 +0100
     2.2 +++ b/docs/src/user.tex	Wed Sep 12 09:43:33 2007 +0100
     2.3 @@ -1683,7 +1683,7 @@ to:
     2.4      section remains to detail a configuration that was used by older Xen
     2.5      versions.}}
     2.6  
     2.7 -Raw image file-backed VBDs amy also be attached to VMs using the 
     2.8 +Raw image file-backed VBDs may also be attached to VMs using the 
     2.9  Linux loopback driver.  The only required change to the raw file 
    2.10  instructions above are to specify the configuration entry as:
    2.11  \begin{quote}
    2.12 @@ -1694,7 +1694,7 @@ instructions above are to specify the co
    2.13    I/O-intensive domains.}  This approach is known to experience
    2.14  substantial slowdowns under heavy I/O workloads, due to the I/O
    2.15  handling by the loopback block device used to support file-backed VBDs
    2.16 -in dom0.  Loopbach support remains for old Xen installations, and users
    2.17 +in dom0.  Loopback support remains for old Xen installations, and users
    2.18  are strongly encouraged to use the blktap-based file support (using 
    2.19  ``{\tt{tap:aio}}'' as described above).
    2.20  
    2.21 @@ -4203,7 +4203,7 @@ on the vnet UDP port:
    2.22  # tcpdump udp port 1798
    2.23  \end{verbatim}
    2.24  
    2.25 -If multicast is not being forwaded between machines you can configure
    2.26 +If multicast is not being forwarded between machines you can configure
    2.27  multicast forwarding using vn. Suppose we have machines hostA on 10.10.0.100
    2.28  and hostB on 10.11.0.100 and that multicast is not forwarded between them.
    2.29  We use vn to configure each machine to forward to the other:
    2.30 @@ -4256,7 +4256,7 @@ as it will forward multicasts received f
    2.31    VMMs} to provide the illusion of contiguous physical memory, in
    2.32    Xen this is used during {\bf live migration}.
    2.33  
    2.34 -\item[Virtual Block Device] Persistant storage available to a virtual
    2.35 +\item[Virtual Block Device] Persistent storage available to a virtual
    2.36    machine, providing the abstraction of an actual block storage device.
    2.37    {\bf VBD}s may be actual block devices, filesystem images, or
    2.38    remote/network storage.