summaryrefslogtreecommitdiffstats
path: root/nest
diff options
context:
space:
mode:
Diffstat (limited to 'nest')
-rw-r--r--nest/cli.c8
-rw-r--r--nest/locks.c6
-rw-r--r--nest/neighbor.c6
-rw-r--r--nest/proto-hooks.c2
-rw-r--r--nest/proto.sgml2
-rw-r--r--nest/rt-fib.c4
-rw-r--r--nest/rt-table.c2
7 files changed, 15 insertions, 15 deletions
diff --git a/nest/cli.c b/nest/cli.c
index 30ac751..a917bcb 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 c1f7331..11489b7 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 89c19ba..c6e2f73 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 29be697..4035fdd 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 3478d93..6e20269 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 28f9fc1..34d862e 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 51da736..ce3bf45 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.