[PATCH] docs: a quick proofreading

[Michael Shigorin]

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

diff --git a/docs/HowItWorks.md b/docs/HowItWorks.md
index b121e4f..cbb4470 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
-use. All events are added in one queue. The queue is implemented on
-the filesystem. Fortunately, our filesystem is located in memory.
+The `udevd` listens to kernel events and performs actions according to its rules.
+Since we cannot run long-running processes or fork 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


--Bu8it7iiRSEf40bY--