From 725270cb1da0672128675924844531e56c6ea64e Mon Sep 17 00:00:00 2001
From: Martin Mares <mj@ucw.cz>
Date: Thu, 8 Jun 2000 12:37:21 +0000
Subject: Fixes for the programmer's manual.

---
 nest/cli.c      | 4 ++--
 nest/proto.sgml | 8 ++++----
 nest/rt-table.c | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

(limited to 'nest')

diff --git a/nest/cli.c b/nest/cli.c
index a917bcb3..e3f9ccf9 100644
--- a/nest/cli.c
+++ b/nest/cli.c
@@ -35,12 +35,12 @@
  * on the current state of command processing.
  *
  * The CLI commands are declared as a part of the configuration grammar
- * by using the |CF_CLI| macro. When a command is received, it's processed
+ * by using the |CF_CLI| macro. When a command is received, it is processed
  * by the same lexical analyzer and parser as used for the configuration, but
  * it's switched to a special mode by prepending a fake token to the text,
  * so that it uses only the CLI command rules. Then the parser invokes
  * an execution routine corresponding to the command, which either constructs
- * the whole reply and returns back or (in case it expects the reply will be long)
+ * the whole reply and returns it back or (in case it expects the reply will be long)
  * it prints a partial reply and asks the CLI module (using the @cont hook)
  * to call it again when the output is transferred to the user.
  *
diff --git a/nest/proto.sgml b/nest/proto.sgml
index 6e20269b..1d4c31a7 100644
--- a/nest/proto.sgml
+++ b/nest/proto.sgml
@@ -8,14 +8,14 @@
 
 <sect1>Introduction
 
-<p>The routing protocols are the BIRD's heart and a fine amount of code
+<p>The routing protocols are the bird's heart and a fine amount of code
 is dedicated to their management and for providing support functions to them.
 (-: Actually, this is the reason why the directory with sources of the core
 code is called <tt/nest/ :-).
 
 <p>When talking about protocols, one need to distinguish between <em/protocols/
 and protocol <em/instances/. A protocol exists exactly once, not depending on whether
-it's configured on not and it can have an arbitrary number of instances corresponding
+it's configured or not and it can have an arbitrary number of instances corresponding
 to its "incarnations" requested by the configuration file. Each instance is completely
 autonomous, has its own configuration, its own status, its own set of routes and its
 own set of interfaces it works on.
@@ -49,7 +49,7 @@ we have decided to supervise them by a pair of simple state machines -- the prot
 state machine and a core state machine.
 
 <p>The <em/protocol state machine/ corresponds to internal state of the protocol
-and the protocol can alter its state whenever it wants to. There exist
+and the protocol can alter its state whenever it wants to. There are
 the following states:
 
 <descrip>
@@ -73,7 +73,7 @@ its state by calling the <func/proto_notify_state/ function.
 The states are traversed according to changes of the protocol state machine, but
 sometimes the transitions are delayed if the core needs to finish some actions
 (for example sending of new routes to the protocol) before proceeding to the
-new state. There exist the following core states:
+new state. There are the following core states:
 
 <descrip>
 	<tag/FS_HUNGRY/ The protocol is down, it doesn't have any routes and
diff --git a/nest/rt-table.c b/nest/rt-table.c
index ce3bf452..e095a14f 100644
--- a/nest/rt-table.c
+++ b/nest/rt-table.c
@@ -13,12 +13,12 @@
  * hold all the information about known networks, the associated routes and
  * their attributes.
  *
- * There exist multiple routing tables (a primary one together with any
+ * There are multiple routing tables (a primary one together with any
  * number of secondary ones if requested by the configuration). Each table
  * is basically a FIB containing entries describing the individual
  * destination networks. For each network (represented by structure &net),
- * there is a one-way linked list of network entries (&rte), the first entry
- * on the list being the best possible one (i.e., the one we currently use
+ * there is a one-way linked list of route entries (&rte), the first entry
+ * on the list being the best one (i.e., the one we currently use
  * for routing), the order of the other ones is undetermined.
  *
  * The &rte contains information specific to the route (preference, protocol
-- 
cgit v1.2.3