Fixes for the programmer's manual.

1 files changed, 18 insertions, 9 deletions

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.
 
-<p>Routing daemons are very complicated things which need to act in real time
+<p>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
 <item><it>Offer powerful route filtering.</it>
 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.
 
 </itemize>
 
@@ -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.
 
-<tagp>Filters</tagp> implement the route filtering language.
+<tagp>The filter</tagp> implements the route filtering language.
 
 <tagp>Protocol modules</tagp> 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.
 
+<p>The modules are statically linked to produce a single executable file
+(except for the client which stands on its own).
+
 <p>The building process is controlled by a set of Makefiles for GNU Make,
 intermixed with several Perl and shell scripts.
 
 <p>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.
 
 <p>The parser of the configuration is generated by the GNU Bison.
 
 <p>The documentation is generated using <file/SGMLtools/ with our own DTD
-and mapping rules. The printed form of the documentation is first converted
+and mapping rules which produce both an online version in HTML and
+a neatly formatted one for printing (first converted
 from SGML to &latex; and then processed by &tex; and <file/dvips/ to
-produce a PostScript file.
+get a PostScript file).
 
 <p>The comments from C sources which form a part of the programmer's
 documentation are extracted using a modified version of the <file/kernel-doc/
 tool.
 
+<p>If you want to work on BIRD, it's highly recommended to configure it
+with a <tt/--enable-debug/ switch which enables some internal consistency
+checks and it also links BIRD with a memory allocation checking library
+if you have one (either <tt/efence/ or <tt/dmalloc/).
 
 <!--
 LocalWords:  IPv IP CLI snippets Perl Autoconf SGMLtools DTD SGML dvips