From 58f7d004fddd2cccdb019be59b6cc7a8abe50510 Mon Sep 17 00:00:00 2001 From: Martin Mares Date: Wed, 7 Jun 2000 13:25:53 +0000 Subject: Fixes to the progdoc. --- nest/cli.c | 8 ++++---- nest/locks.c | 6 +++--- nest/neighbor.c | 6 +++--- nest/proto-hooks.c | 2 +- nest/proto.sgml | 2 +- nest/rt-fib.c | 4 ++-- nest/rt-table.c | 2 +- 7 files changed, 15 insertions(+), 15 deletions(-) (limited to 'nest') 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:

Unless the protocol is in the At any time, the core code can ask the protocol to shut down by calling its stop() hook. +

At any time, the core code can ask the protocol to shut itself down by calling its stop() hook.

The