Fixes to the progdoc.

7 files changed, 15 insertions, 15 deletions

diff --git a/nest/cli.c b/nest/cli.c
index 30ac7510..a917bcb3 100644
--- a/nest/cli.c
+++ b/nest/cli.c
@@ -26,12 +26,12 @@
  * a continuation line, the whole prefix can be replaced by a single
  * white space character.
  *
- * Reply codes starting with 0 describe `action successfully completed' messages,
+ * Reply codes starting with 0 stand for `action successfully completed' messages,
  * 1 means `table entry', 8 `runtime error' and 9 `syntax error'.
  *
  * Each CLI session is internally represented by a &cli structure and a
  * resource pool containing all resources associated with the connection,
- * so that it can be easily freed whenever the connection closes, not depending
+ * so that it can be easily freed whenever the connection gets closed, not depending
  * on the current state of command processing.
  *
  * The CLI commands are declared as a part of the configuration grammar
@@ -40,9 +40,9 @@
  * 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 or (in case it expects the reply will be long)
+ * the whole reply and returns 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 will be transferred to the user.
+ * to call it again when the output is transferred to the user.
  *
  * The @this_cli variable points to a &cli structure of the session being
  * currently parsed, but it's of course available only in command handlers
diff --git a/nest/locks.c b/nest/locks.c
index c1f7331e..11489b77 100644
--- a/nest/locks.c
+++ b/nest/locks.c
@@ -15,14 +15,14 @@
  * occur only when the user specifies an invalid configuration and therefore
  * he deserves to get what he has asked for, but unfortunately they can also
  * arise legitimately when the daemon is reconfigured and there exists (although
- * for a short time period only) an old protocol being shut down and a new one
+ * for a short time period only) an old protocol instance being shut down and a new one
  * willing to start up on the same interface.
  *
  * The solution is very simple: when any protocol wishes to use a network port
- * or some other non-shareable resource, it asks the core to lock it and doesn't
+ * or some other non-shareable resource, it asks the core to lock it and it doesn't
  * use the resource until it's notified that it has acquired the lock.
  *
- * Object locks are represented by &object_lock which is in turn a kind of
+ * Object locks are represented by &object_lock structures which are in turn a kind of
  * resource. Lockable resources are uniquely determined by resource type
  * (%OBJLOCK_UDP for a UDP port etc.), IP address (usually a broadcast or
  * multicast address the port is bound to), port number and interface.
diff --git a/nest/neighbor.c b/nest/neighbor.c
index 89c19ba3..c6e2f734 100644
--- a/nest/neighbor.c
+++ b/nest/neighbor.c
@@ -20,17 +20,17 @@
  * The neighbor cache maintains a collection of neighbor entries. Each
  * entry represents one IP address corresponding to either our directly
  * connected neighbor or our own end of the link (when the scope of the
- * address is set to %SCOPE_HOST) together with data belonging to a
+ * address is set to %SCOPE_HOST) together with per-neighbor data belonging to a
  * single protocol.
  *
  * Active entries represent known neighbors and are stored in a hash
- * table (to allow fast retrieval based on IP address of the node) and
+ * table (to allow fast retrieval based on the IP address of the node) and
  * two linked lists: one global and one per-interface (allowing quick
  * processing of interface change events). Inactive entries exist only
  * when the protocol has explicitly requested it via the %NEF_STICKY
  * flag because it wishes to be notified when the node will again become
  * a neighbor. Such entries are enqueued in a special list which is walked
- * whenever an interface becomes up.
+ * whenever an interface changes its state to up.
  *
  * When a neighbor event occurs (a neighbor gets disconnected or a sticky
  * inactive neighbor becomes connected), the protocol hook neigh_notify()
diff --git a/nest/proto-hooks.c b/nest/proto-hooks.c
index 29be6972..4035fdd7 100644
--- a/nest/proto-hooks.c
+++ b/nest/proto-hooks.c
@@ -9,7 +9,7 @@
 /**
  * DOC: Protocol hooks
  *
- * Each protocol provides a rich set of hook functions referred to by pointers
+ * Each protocol can provide a rich set of hook functions referred to by pointers
  * in either the &proto or &protocol structure. They are called by the core whenever
  * it wants the protocol to perform some action or to notify the protocol about
  * any change of its environment. All of the hooks can be set to %NULL which means
diff --git a/nest/proto.sgml b/nest/proto.sgml
index 3478d93a..6e20269b 100644
--- a/nest/proto.sgml
+++ b/nest/proto.sgml
@@ -67,7 +67,7 @@ the following states:
 <p>Unless the protocol is in the <tt/PS_DOWN/ state, it can decide to change
 its state by calling the <func/proto_notify_state/ function.
 
-<p>At any time, the core code can ask the protocol to shut down by calling its stop() hook.
+<p>At any time, the core code can ask the protocol to shut itself down by calling its stop() hook.
 
 <p>The <em/core state machine/ takes care of the core view of protocol state.
 The states are traversed according to changes of the protocol state machine, but
diff --git a/nest/rt-fib.c b/nest/rt-fib.c
index 28f9fc1c..34d862e2 100644
--- a/nest/rt-fib.c
+++ b/nest/rt-fib.c
@@ -21,7 +21,7 @@
  * We use two-stage hashing where we calculate a 16-bit primary hash key independent
  * on hash table size and then we just divide the primary keys modulo table size
  * to get a real hash key used for determining the bucket containing the node.
- * The lists of nodes in each buckets are sorted according to the primary hash
+ * The lists of nodes in each bucket are sorted according to the primary hash
  * key, hence if we keep the total number of buckets to be a power of two,
  * re-hashing of the structure keeps the relative order of the nodes.
  *
@@ -400,7 +400,7 @@ fit_put(struct fib_iterator *i, struct fib_node *n)
  * @f: FIB to be checked
  *
  * This debugging function audits a FIB by checking its internal consistency.
- * Use when you suspect somebody from corrupting innocent data structures.
+ * Use when you suspect somebody of corrupting innocent data structures.
  */
 void
 fib_check(struct fib *f)
diff --git a/nest/rt-table.c b/nest/rt-table.c
index 51da7366..ce3bf452 100644
--- a/nest/rt-table.c
+++ b/nest/rt-table.c
@@ -16,7 +16,7 @@
  * There exist 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)
+ * 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
  * for routing), the order of the other ones is undetermined.