diff options
Diffstat (limited to 'nest')
| -rw-r--r-- | nest/cli.c | 8 | ||||
| -rw-r--r-- | nest/locks.c | 6 | ||||
| -rw-r--r-- | nest/neighbor.c | 6 | ||||
| -rw-r--r-- | nest/proto-hooks.c | 2 | ||||
| -rw-r--r-- | nest/proto.sgml | 2 | ||||
| -rw-r--r-- | nest/rt-fib.c | 4 | ||||
| -rw-r--r-- | nest/rt-table.c | 2 |
7 files changed, 15 insertions, 15 deletions
@@ -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. |