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