[PATCH] docs: a quick proofreading

[Michael Shigorin]

---
 docs/HowItWorks.md    | 34 +++++++++++++++++-----------------
 docs/UeventDetails.md | 18 +++++++++---------
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/docs/HowItWorks.md b/docs/HowItWorks.md
index b121e4f..df91666 100644
--- a/docs/HowItWorks.md
+++ b/docs/HowItWorks.md
@@ -1,10 +1,10 @@
 # How it works ?
 
-When we talking about event-driven infrastructure it means that there is no
+When we talk about event-driven infrastructure it means that there is no
 hardcoded sequence of steps to mount system root.
 
-The initramfs init starts few services: udevd, ueventd, polld. The interaction
-between the services looks like this:
+The initramfs init starts a few services: udevd, ueventd, polld.
+The interaction between these services looks like this:
 
 ```
 .==========.        .----------------.        .------------------.
@@ -28,28 +28,28 @@ between the services looks like this:
 '---------'        '-----------------'
 ```
 
-The `udevd` listen for kernel events and according to his rules performs
-actions. Since we cannot run long-running processes, the forked processes we run
-a special `filters` (small simple scripts) to save event information for future
+The `udevd` listens to kernel events and performs actions according to its rules.
+Since we cannot run long-running processes, the forked processes we run
+special `filters` (small simple scripts) to save event information for future
 use. All events are added in one queue. The queue is implemented on
 the filesystem. Fortunately, our filesystem is located in memory.
 
-To process saved events we use `ueventd`. The `ueventd` is a simple queue
-deamon. Each event in the queue is processed one by one in the order of arrival,
-but daemon can process several queues in parallel. This deamon calls `handlers`
-for events in the queue. The `handler` implements one aspect of boot (lvm, raid,
-luks, mount device, etc).
+`ueventd` processes saved events. It's is a simple queue daemon. Each event in
+the queue is processed one by one in the order of arrival, but daemon can
+process several queues in parallel. It calls `handlers` for events in the
+queue. A `handler` implements one aspect of boot (lvm, raid, luks, mount
+device, etc).
 
-For example, if we got events about all block devices needed for raid then
+For example, if we got events about all block devices needed for MD RAID then
 the raid-handler will assemble it. This in turn will spawn a new kernel event
-about the appearance of /dev/md0. Now, mount-handler can check it and if this is
-the root of the system, then handler will mount this block device.
+about the appearance of /dev/md0. Now, mount-handler can check it and if it
+contains the root filesystem, then handler will mount this block device.
 
 So, we mounted some block devices somewhere. We need something that would make
-a decision that we have all the conditions for real system boot. The `polld` is
+a decision that we met all the conditions for real system boot. The `polld` is
 responsible for this. The server periodically runs `extenders` scripts that
-perform checks (console is not active, the system init was found, etc.), and
-if all scripts succeed, the server initiates a system boot.
+perform checks (console is not active, the system init was found, etc.),
+and if all scripts succeed, the server initiates a system boot.
 
 This scheme is used to mount system root device, resume system, configure
 network. Basically it's used for everything based on kernel events.
diff --git a/docs/UeventDetails.md b/docs/UeventDetails.md
index d749c73..a72fd80 100644
--- a/docs/UeventDetails.md
+++ b/docs/UeventDetails.md
@@ -1,10 +1,10 @@
 # Ueventd details
 
-The `ueventd` is a queue deamon. The task of this server is to process events
-from the queue. Each event in the queue is processed one by one in the order
-of arrival, but daemon can process several queues in parallel.
+`ueventd` is a queue daemon. The task of this server is to process events
+from the queue. Each event in its queue is processed one by one in the order
+of arrival, but several queues can be processed in parallel.
 
-Queues are implemented on the filesystem. All incoming events are placed:
+Queues are implemented on the filesystem. All incoming events are placed as:
 
 `/.initrd/uevent/queues/<QUEUE>/<EVENT>`
 
@@ -22,20 +22,20 @@ Handlers come in two types:
 
 This is an old version of `handlers`. Every handler is not called for every
 event, but sequentially. A handler can analyze all the events that have arrived
-and delete them if considers it necessary.
+and discard those if deemed necessary.
 
 2. `/lib/uevent/handlers/<QUEUE>/[0-9][0-9][0-9]-<HANDLER>`
 
-This is a new way how to handle events. Handlers as an argument gets a directory
-with events. Just like in the first case, the handler is not called for each
-event.
+This is the new way to handle events. Handlers gets a directory with events
+as an argument. Just like the first case, the handler is not called for
+each event.
 
 Processed events are prefixed with `done.` or deleted.
 
 ## uevent API
 
 All `filters` and `handlers` should use `/bin/uevent-sh-functions` as
-an interface to events.
+the interface to events.
 
 `make_event` is used to create a new event. It will not be published yet.
 The `<QUEUE>` is passed as an argument. This function returns the eventfile.
-- 
2.10.4


--zhXaljGHf11kAtnf--