docs: Improve documentation

Fix some inconsistencies (tabs and punctuation)
and try to improve grammar and spelling.

Cc: Juan Quintela <quintela@redhat.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>

1 files changed, 28 insertions, 28 deletions

diff --git a/docs/migration.txt b/docs/migration.txt
index 69d53837c..4848c1e52 100644
--- a/docs/migration.txt
+++ b/docs/migration.txt
@@ -1,21 +1,21 @@
 = Migration =
 
 QEMU has code to load/save the state of the guest that it is running.
-This are two complementary operations.  Saving the state just does
+These are two complementary operations.  Saving the state just does
 that, saves the state for each device that the guest is running.
 Restoring a guest is just the opposite operation: we need to load the
 state of each device.
 
-For this to work, QEMU has to be launch with the same arguments the
+For this to work, QEMU has to be launched with the same arguments the
 two times.  I.e. it can only restore the state in one guest that has
 the same devices that the one it was saved (this last requirement can
-be relaxed a bit, but for now we can consider that configuration have
+be relaxed a bit, but for now we can consider that configuration has
 to be exactly the same).
 
 Once that we are able to save/restore a guest, a new functionality is
 requested: migration.  This means that QEMU is able to start in one
-machine and being "migrated" to other machine.  I.e. being moved to
-other machine.
+machine and being "migrated" to another machine.  I.e. being moved to
+another machine.
 
 Next was the "live migration" functionality.  This is important
 because some guests run with a lot of state (specially RAM), and it
@@ -24,7 +24,7 @@ migration allows the guest to continue running while the state is
 transferred.  Only while the last part of the state is transferred has
 the guest to be stopped.  Typically the time that the guest is
 unresponsive during live migration is the low hundred of milliseconds
-(notice that this depends on lot of things).
+(notice that this depends on a lot of things).
 
 === Types of migration ===
 
@@ -35,9 +35,9 @@ to do migration:
 - unix migration: do the migration using unix sockets
 - exec migration: do the migration using the stdin/stdout through a process.
 - fd migration: do the migration using an file descriptor that is
-  passed to QEMU.  QEMU don't cares how this file descriptor is opened.
+  passed to QEMU.  QEMU doesn't care how this file descriptor is opened.
 
-All this four migration protocols use the same infrastructure to
+All these four migration protocols use the same infrastructure to
 save/restore state devices.  This infrastructure is shared with the
 savevm/loadvm functionality.
 
@@ -49,21 +49,21 @@ This is used for RAM and block devices.  It is not yet ported to vmstate.
 === What is the common infrastructure ===
 
 QEMU uses a QEMUFile abstraction to be able to do migration.  Any type
-of migration that what to use QEMU infrastructure has to create a
+of migration that wants to use QEMU infrastructure has to create a
 QEMUFile with:
 
 QEMUFile *qemu_fopen_ops(void *opaque,
-	 		 QEMUFilePutBufferFunc *put_buffer,
+                         QEMUFilePutBufferFunc *put_buffer,
                          QEMUFileGetBufferFunc *get_buffer,
                          QEMUFileCloseFunc *close,
                          QEMUFileRateLimit *rate_limit,
                          QEMUFileSetRateLimit *set_rate_limit,
-			 QEMUFileGetRateLimit *get_rate_limit);
+                         QEMUFileGetRateLimit *get_rate_limit);
 
 The functions have the following functionality:
 
 This function writes a chunk of data to a file at the given position.
-The pos argument can be ignored if the file is only being used for
+The pos argument can be ignored if the file is only used for
 streaming.  The handler should try to write all of the data it can.
 
 typedef int (QEMUFilePutBufferFunc)(void *opaque, const uint8_t *buf,
@@ -76,18 +76,18 @@ bytes actually read should be returned.
 typedef int (QEMUFileGetBufferFunc)(void *opaque, uint8_t *buf,
                                     int64_t pos, int size);
 
-Close a file and return an error code
+Close a file and return an error code.
 
 typedef int (QEMUFileCloseFunc)(void *opaque);
 
-Called to determine if the file has exceeded it's bandwidth allocation.  The
+Called to determine if the file has exceeded its bandwidth allocation.  The
 bandwidth capping is a soft limit, not a hard limit.
 
 typedef int (QEMUFileRateLimit)(void *opaque);
 
 Called to change the current bandwidth allocation. This function must return
 the new actual bandwidth. It should be new_rate if everything goes OK, and
-the old rate otherwise
+the old rate otherwise.
 
 typedef size_t (QEMUFileSetRateLimit)(void *opaque, size_t new_rate);
 typedef size_t (QEMUFileGetRateLimit)(void *opaque);
@@ -111,8 +111,8 @@ version.  When we migrate a device, we save/load the state as a series
 of fields.  Some times, due to bugs or new functionality, we need to
 change the state to store more/different information.  We use the
 version to identify each time that we do a change.  Each version is
-associated with a series of fields saved.  The save_state always save
-the state as the newer version.  But load_state some times is able to
+associated with a series of fields saved.  The save_state always saves
+the state as the newer version.  But load_state sometimes is able to
 load state from an older version.
 
  === Legacy way ===
@@ -135,14 +135,14 @@ typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
 
 The important functions for the device state format are the save_state
 and load_state.  Notice that load_state receives a version_id
-parameter to know what state format is receiving.  save_state don't
-have a version_id parameter because it uses always the latest version.
+parameter to know what state format is receiving.  save_state doesn't
+have a version_id parameter because it always uses the latest version.
 
 === VMState ===
 
 The legacy way of saving/loading state of the device had the problem
-that we have to maintain in sync two functions.  If we did one change
-in one of them and not on the other, we got a failed migration.
+that we have to maintain two functions in sync.  If we did one change
+in one of them and not in the other, we would get a failed migration.
 
 VMState changed the way that state is saved/loaded.  Instead of using
 a function to save the state and another to load it, it was changed to
@@ -173,7 +173,7 @@ We registered this with:
 
     vmstate_register(NULL, 0, &vmstate_kbd, s);
 
-Note: talk about how vmstate <-> qdev interact, and what the instance id's mean.
+Note: talk about how vmstate <-> qdev interact, and what the instance ids mean.
 
 You can search for VMSTATE_* macros for lots of types used in QEMU in
 hw/hw.h.
@@ -182,7 +182,7 @@ hw/hw.h.
 
 You can see that there are several version fields:
 
-- version_id: the maximum version_id supported by VMState for that device
+- version_id: the maximum version_id supported by VMState for that device.
 - minimum_version_id: the minimum version_id that VMState is able to understand
   for that device.
 - minimum_version_id_old: For devices that were not able to port to vmstate, we can
@@ -195,7 +195,7 @@ deprecated and will be removed when no more users are left.
 
 ===  Massaging functions ===
 
-Some times, it is not enough to be able to save the state directly
+Sometimes, it is not enough to be able to save the state directly
 from one structure, we need to fill the correct values there.  One
 example is when we are using kvm.  Before saving the cpu state, we
 need to ask kvm to copy to QEMU the state that it is using.  And the
@@ -227,14 +227,14 @@ makes very complicated to fix bugs in stable branches.  If we need to
 add anything to the state to fix a bug, we have to disable migration
 to older versions that don't have that bug-fix (i.e. a new field).
 
-But some time, that bug-fix is only needed sometimes, not always.  For
+But sometimes, that bug-fix is only needed sometimes, not always.  For
 instance, if the device is in the middle of a DMA operation, it is
 using a specific functionality, ....
 
 It is impossible to create a way to make migration from any version to
-any other version to work.  But we can do better that only allowing
+any other version to work.  But we can do better than only allowing
 migration from older versions no newer ones.  For that fields that are
-only needed sometimes, we add the idea of subsections.  a subsection
+only needed sometimes, we add the idea of subsections.  A subsection
 is "like" a device vmstate, but with a particularity, it has a Boolean
 function that tells if that values are needed to be sent or not.  If
 this functions returns false, the subsection is not sent.
@@ -266,7 +266,7 @@ const VMStateDescription vmstate_ide_drive_pio_state = {
     .fields      = (VMStateField []) {
         VMSTATE_INT32(req_nb_sectors, IDEState),
         VMSTATE_VARRAY_INT32(io_buffer, IDEState, io_buffer_total_len, 1,
-			     vmstate_info_uint8, uint8_t),
+                             vmstate_info_uint8, uint8_t),
         VMSTATE_INT32(cur_io_buffer_offset, IDEState),
         VMSTATE_INT32(cur_io_buffer_len, IDEState),
         VMSTATE_UINT8(end_transfer_fn_idx, IDEState),