From 725270cb1da0672128675924844531e56c6ea64e Mon Sep 17 00:00:00 2001 From: Martin Mares Date: Thu, 8 Jun 2000 12:37:21 +0000 Subject: Fixes for the programmer's manual. --- conf/cf-lex.l | 4 +- conf/conf.c | 4 +- doc/prog-intro.sgml | 27 +++++++++----- doc/tex/birddoc.sty | 4 +- filter/filter.c | 32 ++++++++-------- lib/ip.c | 2 +- lib/resource.sgml | 2 +- nest/cli.c | 4 +- nest/proto.sgml | 8 ++-- nest/rt-table.c | 6 +-- proto/ospf/ospf.c | 101 ++++++++++++++++++++++++++------------------------ proto/static/static.c | 13 +++---- sysdep/unix/krt.c | 5 ++- sysdep/unix/log.c | 4 +- 14 files changed, 114 insertions(+), 102 deletions(-) diff --git a/conf/cf-lex.l b/conf/cf-lex.l index 9dfe10e..ce2ce40 100644 --- a/conf/cf-lex.l +++ b/conf/cf-lex.l @@ -456,7 +456,7 @@ cf_symbol_class_name(struct symbol *sym) * Grammar snippets are files (usually with extension |.Y|) contributed * by various BIRD modules in order to provide information about syntax of their * configuration and their CLI commands. Each snipped consists of several - * section, each of them starting with a special keyword: |CF_HDR| for + * sections, each of them starting with a special keyword: |CF_HDR| for * a list of |#include| directives needed by the C code, |CF_DEFINES| * for a list of C declarations, |CF_DECLS| for |bison| declarations * including keyword definitions specified as |CF_KEYWORDS|, |CF_GRAMMAR| @@ -473,5 +473,5 @@ cf_symbol_class_name(struct symbol *sym) * * Values of |enum| filter types can be defined using |CF_ENUM| with * the following parameters: name of filter type, prefix common for all - * literals of this type, names of all the possible values. + * literals of this type and names of all the possible values. */ diff --git a/conf/conf.c b/conf/conf.c index d6e2425..be2d771 100644 --- a/conf/conf.c +++ b/conf/conf.c @@ -9,7 +9,7 @@ /** * DOC: Configuration manager * - * Configuration of BIRD is complex, yet straightforward. There exist three + * Configuration of BIRD is complex, yet straightforward. There are three * modules taking care of the configuration: config manager (which takes care * of storage of the config information and controls switching between configs), * lexical analyzer and parser. @@ -18,7 +18,7 @@ * accompanied by a linear pool from which all information associated * with the config and pointed to by the &config structure is allocated. * - * There can exist up four different configurations at one time: an active + * There can exist up to four different configurations at one time: an active * one (pointed to by @config), configuration we are just switching from * (@old_config), one queued for the next reconfiguration (@future_config; * if it's non-%NULL and the user wants to reconfigure once again, we just diff --git a/doc/prog-intro.sgml b/doc/prog-intro.sgml index f584f69..a8eabe5 100644 --- a/doc/prog-intro.sgml +++ b/doc/prog-intro.sgml @@ -6,7 +6,7 @@ design decisions and rationale behind them. It also contains documentation on all the essential components of the system and their interfaces. -

Routing daemons are very complicated things which need to act in real time +

Routing daemons are complicated things which need to act in real time to complex sequences of external events, respond correctly even to the most erroneous behavior of their environment and still handle enormous amount of data with reasonable speed. Due to all of this, their design is very tricky as one needs to carefully @@ -47,7 +47,7 @@ Easily solvable by abstracting out routing tables and the corresponding operatio Offer powerful route filtering. There already were several attempts to incorporate route filters to a dynamic router, but most of them have used simple sequences of filtering rules which were very inflexible -and hard to use for any non-trivial filters. We've decided to employ a simple loop-free +and hard to use for non-trivial filters. We've decided to employ a simple loop-free programming language having access to all the route attributes and being able to modify the most of them. @@ -65,8 +65,7 @@ the routing process which are not affected by the change. In addition to the online reconfiguration, a routing daemon should be able to communicate with the user and with many other programs (primarily scripts used for network maintenance) in order to make it possible to inspect contents of routing tables, status of all -routing protocols and also to control their behavior (i.e., it should be possible -to disable, enable or reset a protocol without restarting all the others). To achieve +routing protocols and also to control their behavior (disable, enable or reset a protocol without restarting all the others). To achieve this, we implement a simple command-line protocol based on those used by FTP and SMTP (that is textual commands and textual replies accompanied by a numeric code which makes them both readable to a human and easy to recognize in software). @@ -77,7 +76,9 @@ of all the routing protocols and also of the user interface parts and to hope th the scheduler will assign time to them in a fair enough manner. This is surely a good solution, but we have resisted the temptation and preferred to avoid the overhead of threading and the large number of locks involved and preferred a event driven architecture with -our own scheduling of events. +our own scheduling of events. An unpleasant consequence of such an approach +is that long lasting tasks must be split to more parts linked by special +events or timers to make the CPU available for other tasks as well. @@ -106,7 +107,7 @@ grammar rules and the corresponding snippets of C code. For each group of code modules (core, each protocol, filters) there exist a configuration module taking care of all the related configuration stuff. -Filters implement the route filtering language. +The filter implements the route filtering language. Protocol modules implement the individual routing protocols. @@ -125,25 +126,33 @@ preferred the simplicity and straightforward nature of C which gives us fine control over all implementation details and on the other hand enough instruments to build the abstractions we need. +

The modules are statically linked to produce a single executable file +(except for the client which stands on its own). +

The building process is controlled by a set of Makefiles for GNU Make, intermixed with several Perl and shell scripts.

The initial configuration of the daemon, detection of system features and selection of the right modules to include for the particular OS and the set of protocols the user has chosen is performed by a configure -script created using GNU Autoconf. +script generated by GNU Autoconf.

The parser of the configuration is generated by the GNU Bison.

The documentation is generated using The comments from C sources which form a part of the programmer's documentation are extracted using a modified version of the If you want to work on BIRD, it's highly recommended to configure it +with a We've tried to solve this problem by employing a resource tracking system which keeps track of all the resources allocated by all the modules of BIRD, deallocates everything automatically when a module -shuts down and it's is able to print out the list of resources and +shuts down and it is able to print out the list of resources and the corresponding modules they are allocated by.

Each allocated resource (from now we'll speak about allocated diff --git a/nest/cli.c b/nest/cli.c index a917bcb..e3f9ccf 100644 --- a/nest/cli.c +++ b/nest/cli.c @@ -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 6e20269..1d4c31a 100644 --- a/nest/proto.sgml +++ b/nest/proto.sgml @@ -8,14 +8,14 @@ Introduction -

The routing protocols are the BIRD's heart and a fine amount of code +

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 When talking about protocols, one need to distinguish between The @@ -73,7 +73,7 @@ its state by calling the -- cgit v1.2.3