Spelling fixes to progdoc.
This commit is contained in:
Martin Mares
parent
e403aa89e5
commit
2e9b24211a
18 changed files with 46 additions and 46 deletions
|
|
@ -7,9 +7,9 @@
|
|||
*/
|
||||
|
||||
/**
|
||||
* DOC: Lexical analyser
|
||||
* DOC: Lexical analyzer
|
||||
*
|
||||
* The lexical analyser used for configuration files and CLI commands
|
||||
* The lexical analyzer used for configuration files and CLI commands
|
||||
* is generated using the |flex| tool accompanied with a couple of
|
||||
* functions maintaining the hash tables containing information about
|
||||
* symbols and keywords.
|
||||
|
|
@ -341,7 +341,7 @@ cf_lex_init_kh(void)
|
|||
* cf_lex_init - initialize the lexer
|
||||
* @is_cli: true if we're going to parse CLI command, false for configuration
|
||||
*
|
||||
* cf_lex_init() initializes the lexical analyser and prepares it for
|
||||
* cf_lex_init() initializes the lexical analyzer and prepares it for
|
||||
* parsing of a new input.
|
||||
*/
|
||||
void
|
||||
|
|
@ -448,7 +448,7 @@ cf_symbol_class_name(struct symbol *sym)
|
|||
/**
|
||||
* DOC: Parser
|
||||
*
|
||||
* Both the configuration and CLI commands are analysed using a syntax
|
||||
* Both the configuration and CLI commands are analyzed using a syntax
|
||||
* driven parser generated by the |bison| tool from a grammar which
|
||||
* is constructed from information gathered from grammar snippets by
|
||||
* the |gen_parser.m4| script.
|
||||
|
|
@ -460,7 +460,7 @@ cf_symbol_class_name(struct symbol *sym)
|
|||
* 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|
|
||||
* for the grammar rules, |CF_CODE| for auxillary C code and finally
|
||||
* for the grammar rules, |CF_CODE| for auxiliary C code and finally
|
||||
* |CF_END| at the end of the snippet.
|
||||
*
|
||||
* To create references between the snippets, it's possible to define
|
||||
|
|
@ -468,7 +468,7 @@ cf_symbol_class_name(struct symbol *sym)
|
|||
* alternative to a multi-part rule.
|
||||
*
|
||||
* CLI commands are defined using a |CF_CLI| macro. Its parameters are:
|
||||
* the list of keywords determining the command, the list of paramaters,
|
||||
* the list of keywords determining the command, the list of parameters,
|
||||
* help text for the parameters and help text for the command.
|
||||
*
|
||||
* Values of |enum| filter types can be defined using |CF_ENUM| with
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
* Configuration of BIRD is complex, but straightforward. There exist three
|
||||
* modules taking care of the configuration: config manager (which takes care
|
||||
* of storage of config information and controls switching between configs),
|
||||
* lexical analyser and parser.
|
||||
* lexical analyzer and parser.
|
||||
*
|
||||
* The configuration manager stores each config as a &config structure
|
||||
* accompanied by a linear pool from which all information associated
|
||||
|
|
@ -32,7 +32,7 @@
|
|||
* config by calling config_commit().
|
||||
*
|
||||
* CLI commands are parsed in a very similar way -- there is also a stripped-down
|
||||
* &config structure associated with them and they are lexed and parsed by the
|
||||
* &config structure associated with them and they are lex-ed and parsed by the
|
||||
* same functions, only a special fake token is prepended before the command
|
||||
* text to make the parser recognize only the rules corresponding to CLI commands.
|
||||
*/
|
||||
|
|
@ -91,10 +91,10 @@ config_alloc(byte *name)
|
|||
* config_parse() reads input by calling a hook function pointed to
|
||||
* by @cf_read_hook and parses it according to the configuration
|
||||
* grammar. It also calls all the preconfig and postconfig hooks
|
||||
* before resp. after parsing.
|
||||
* before, resp. after parsing.
|
||||
*
|
||||
* Result: 1 if the config has been parsed successfully, 0 if any
|
||||
* error has occured (such as anybody calling cf_error()) and
|
||||
* error has occurred (such as anybody calling cf_error()) and
|
||||
* the @err_msg field has been set to the error message.
|
||||
*/
|
||||
int
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
* Filter consists of tree of &f_inst structures, one structure per
|
||||
* "instruction". Each &f_inst contains code, aux value which is
|
||||
* usually type of data this instruction operates on, and two generic
|
||||
* arguments (a1, a2). Some instructinos contain pointer(s) to other
|
||||
* arguments (a1, a2). Some instructions contain pointer(s) to other
|
||||
* instructions in their (a1, a2) fields.
|
||||
*
|
||||
* Filters use structure &f_val for its variables. Each &f_val
|
||||
|
|
@ -256,7 +256,7 @@ rta_cow(void)
|
|||
|
||||
/**
|
||||
* interpret
|
||||
* @what: filter to interrpret
|
||||
* @what: filter to interpret
|
||||
*
|
||||
* Interpret given tree of filter instructions. This is core function
|
||||
* of filter system and does all the hard work.
|
||||
|
|
@ -767,7 +767,7 @@ i_same(struct f_inst *f1, struct f_inst *f2)
|
|||
* f_run - external entry point to filters
|
||||
* @filter: pointer to filter to run
|
||||
* @tmp_attrs: where to store newly generated temporary attributes
|
||||
* @rte: pointer to pointer to rte being filtered. When route is modified, this is changed with rte_cow.
|
||||
* @rte: pointer to pointer to &rte being filtered. When route is modified, this is changed with rte_cow().
|
||||
* @tmp_pool: all filter allocations go from this pool
|
||||
* @flags: flags
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ ipsum_verify(void *frag, unsigned len, ...)
|
|||
* @frag: first packet fragment
|
||||
* @len: length in bytes
|
||||
*
|
||||
* This function caculates a one's complement checksum of a given fragmented
|
||||
* This function calculates a one's complement checksum of a given fragmented
|
||||
* packet.
|
||||
*
|
||||
* It uses all the clever tricks described in RFC 1071 to speed
|
||||
|
|
|
|||
6
lib/ip.c
6
lib/ip.c
|
|
@ -19,7 +19,7 @@
|
|||
*/
|
||||
|
||||
/**
|
||||
* ip_scope_text - get texual representation of address scope
|
||||
* ip_scope_text - get textual representation of address scope
|
||||
* @scope: scope (%SCOPE_xxx)
|
||||
*
|
||||
* Returns a pointer to a textual name of the scope given.
|
||||
|
|
@ -145,7 +145,7 @@ void ipa_ntoh(ip_addr x) { DUMMY }
|
|||
*
|
||||
* ipa_classify() returns an address class of @x, that is a bitwise or
|
||||
* of address type (%IADDR_INVALID, %IADDR_HOST, %IADDR_BROADCAST, %IADDR_MULTICAST)
|
||||
* with adress scope (%SCOPE_HOST to %SCOPE_UNIVERSE) or -1 (%IADDR_INVALID)
|
||||
* with address scope (%SCOPE_HOST to %SCOPE_UNIVERSE) or -1 (%IADDR_INVALID)
|
||||
* for an invalid address.
|
||||
*/
|
||||
int ipa_classify(ip_addr x) { DUMMY }
|
||||
|
|
@ -254,7 +254,7 @@ char *ip_ntox(ip_addr a, char *buf) { DUMMY }
|
|||
*
|
||||
* This function parses a textual IP address representation and
|
||||
* stores the decoded address to a variable pointed to by @o.
|
||||
* Returns 0 if a parse error has occured, else 0.
|
||||
* Returns 0 if a parse error has occurred, else 0.
|
||||
*/
|
||||
int ip_pton(char *a, ip_addr *o) { DUMMY }
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
* failure it calls die() to quit the program instead of returning
|
||||
* a %NULL pointer.
|
||||
*
|
||||
* Whereever possible, please use the memory resources instead.
|
||||
* Wherever possible, please use the memory resources instead.
|
||||
*/
|
||||
void *
|
||||
xmalloc(unsigned size)
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@
|
|||
*
|
||||
* 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 the same lexical analyser and parser as used for the configuration, but
|
||||
* 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
|
||||
|
|
|
|||
|
|
@ -212,7 +212,7 @@ void neigh_notify(neighbor *neigh)
|
|||
* to convert the protocol attributes embedded directly in the &rte
|
||||
* to temporary extended attributes in order to distribute them
|
||||
* to other protocols or to filters. make_tmp_attrs() creates
|
||||
* an &ea_list in the linpool @pool, fills it with values of the
|
||||
* an &ea_list in the linear pool @pool, fills it with values of the
|
||||
* temporary attributes and returns a pointer to it.
|
||||
*/
|
||||
ea_list *make_tmp_attrs(rte *e, struct linpool *pool)
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ proto_relink(struct proto *p)
|
|||
* with data specific to the protocol)
|
||||
*
|
||||
* When a new configuration has been read in, the core code starts
|
||||
* initializing all the protocol instandces configured by calling their
|
||||
* initializing all the protocol instances configured by calling their
|
||||
* init() hooks with the corresponding instance configuration. The initialization
|
||||
* code of the protocol is expected to create a new instance according to the
|
||||
* configuration by calling this function and then modifying the default settings
|
||||
|
|
@ -456,7 +456,7 @@ protos_dump_all(void)
|
|||
*
|
||||
* After the platform specific initialization code uses protos_build()
|
||||
* to add all the standard protocols, it should call proto_build() for
|
||||
* all platform specific protocols to infrom the core that they exist.
|
||||
* all platform specific protocols to inform the core that they exist.
|
||||
*/
|
||||
void
|
||||
proto_build(struct protocol *p)
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
* dynamic attributes represented by a linked list of &ea_list
|
||||
* structures, each of them consisting of an array of &eattr's containing
|
||||
* the individual attributes. An attribute can be specified more than once
|
||||
* in the &ea_list chain and in such case the first occurence overrides
|
||||
* in the &ea_list chain and in such case the first occurrence overrides
|
||||
* the others. This semantics is used especially when someone (for example
|
||||
* a filter) wishes to alter values of several dynamic attributes, but
|
||||
* it wants to preserve the original attribute lists maintained by
|
||||
|
|
@ -33,7 +33,7 @@
|
|||
* embedded 32-bit value or a pointer to a &adata structure holding attribute
|
||||
* contents.
|
||||
*
|
||||
* There exist two variants of &rta's -- cached and uncached ones. Uncached
|
||||
* There exist two variants of &rta's -- cached and un-cached ones. Un-cached
|
||||
* &rta's can have arbitrarily complex structure of &ea_list's and they
|
||||
* can be modified by any module in the route processing chain. Cached
|
||||
* &rta's have their attribute lists normalized (that means at most one
|
||||
|
|
@ -103,7 +103,7 @@ ea__find(ea_list *e, unsigned id)
|
|||
* @id: attribute ID to search for
|
||||
*
|
||||
* Given an extended attribute list, ea_find() searches for a first
|
||||
* occurence of an attribute with specified ID, returning either a pointer
|
||||
* occurrence of an attribute with specified ID, returning either a pointer
|
||||
* to its &eattr structure or %NULL if no such attribute exists.
|
||||
*/
|
||||
eattr *
|
||||
|
|
@ -214,7 +214,7 @@ ea_do_prune(ea_list *e)
|
|||
* within each of its entries.
|
||||
*
|
||||
* If an attribute occurs multiple times in a single &ea_list,
|
||||
* ea_sort() leaves only the first (the only significant) occurence.
|
||||
* ea_sort() leaves only the first (the only significant) occurrence.
|
||||
*/
|
||||
void
|
||||
ea_sort(ea_list *e)
|
||||
|
|
@ -637,9 +637,9 @@ rta_rehash(void)
|
|||
|
||||
/**
|
||||
* rta_lookup - look up a &rta in attribute cache
|
||||
* @o: a uncached &rta
|
||||
* @o: a un-cached &rta
|
||||
*
|
||||
* rta_lookup() gets an uncached &rta structure and returns its cached
|
||||
* rta_lookup() gets an un-cached &rta structure and returns its cached
|
||||
* counterpart. It starts with examining the attribute cache to see whether
|
||||
* there exists a matching entry. If such an entry exists, it's returned and
|
||||
* its use count is incremented, else a new entry is created with use count
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
/**
|
||||
* DOC: Direct
|
||||
*
|
||||
* The Direct protocol works by convering all ifa_notify() events it receives
|
||||
* The Direct protocol works by converting all ifa_notify() events it receives
|
||||
* to rte_update() calls for the corresponding network.
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ rte_find(net *net, struct proto *p)
|
|||
/**
|
||||
* rte_get_temp - get a temporary &rte
|
||||
* @a: attributes to assign to the new route (a &rta; in case it's
|
||||
* uncached, rte_update() will create a cached copy automatically)
|
||||
* un-cached, rte_update() will create a cached copy automatically)
|
||||
*
|
||||
* Create a temporary &rte and bind it with the attributes @a.
|
||||
* Also set route preference to the default preference set for
|
||||
|
|
@ -447,7 +447,7 @@ rte_update_unlock(void)
|
|||
*
|
||||
* This function is called by the routing protocols whenever they discover
|
||||
* a new route or wish to update/remove an existing route. The right announcement
|
||||
* sequence is to build route attributes first (either uncached with @aflags set
|
||||
* sequence is to build route attributes first (either un-cached with @aflags set
|
||||
* to zero or a cached one using rta_lookup(); in this case please note that
|
||||
* you need to increase the use count of the attributes yourself by calling
|
||||
* rta_clone()), call rte_get_temp() to obtain a temporary &rte, fill in all
|
||||
|
|
@ -1125,7 +1125,7 @@ static inline net *net_get(rtable *tab, ip_addr addr, unsigned len)
|
|||
* shared with anyone else (and especially that it isn't stored in any routing
|
||||
* table).
|
||||
*
|
||||
* Result: a pointer to the new writeable &rte.
|
||||
* Result: a pointer to the new writable &rte.
|
||||
*/
|
||||
static inline rte * rte_cow(rte *r)
|
||||
{ DUMMY; }
|
||||
|
|
|
|||
|
|
@ -566,12 +566,12 @@ bgp_init(struct proto_config *C)
|
|||
* bgp_error - report a protocol error
|
||||
* @c: connection
|
||||
* @code: error code (according to the RFC)
|
||||
* @subcode: error subcode
|
||||
* @subcode: error sub-code
|
||||
* @data: data to be passed in the Notification message
|
||||
* @len: length of the data
|
||||
*
|
||||
* bgp_error() sends a notification packet to tell the other side that a protocol
|
||||
* error has occured (including the data considered erroneous if possible) and
|
||||
* error has occurred (including the data considered erroneous if possible) and
|
||||
* closes the connection.
|
||||
*/
|
||||
void
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@
|
|||
* DOC: Routing information protocol
|
||||
*
|
||||
* Rip is pretty simple protocol so half of this code is interface
|
||||
* with core. We maintain our own linklist of &rip_entry - it serves
|
||||
* as our small routing table. Rip never adds into this linklist at
|
||||
* with core. We maintain our own linked list of &rip_entry -- it serves
|
||||
* as our small routing table. Rip never adds into this linked list at
|
||||
* packet reception; instead, it lets core know about data from packet,
|
||||
* and waits for core to call our rip_rte_notify.
|
||||
*
|
||||
|
|
@ -30,7 +30,7 @@
|
|||
* walked, and packet is generated using rip_tx_prepare(). This gets
|
||||
* tricky because we may need to send more than one packet to one
|
||||
* destination. Struct &rip_connection is used to hold info such as how
|
||||
* many of &rip_entry ies we already send, and is also used to protect
|
||||
* many of &rip_entry's we already send, and is also used to protect
|
||||
* from two concurrent sends to one destination. Each &rip_interface has
|
||||
* at most one &rip_connection.
|
||||
*
|
||||
|
|
@ -483,8 +483,8 @@ rip_dump_entry( struct rip_entry *e )
|
|||
*
|
||||
* Broadcast routing tables periodically (using rip_tx) and kill
|
||||
* routes that are too old. Rip keeps its own entries in main routing
|
||||
* table linked by link list (functions rip_rte_insert and
|
||||
* rip_rte_delete are responsible for that), walks this list in timer
|
||||
* table linked by link list (functions rip_rte_insert() and
|
||||
* rip_rte_delete() are responsible for that), walks this list in timer
|
||||
* and in case entry is too old, it is discarded.
|
||||
*/
|
||||
|
||||
|
|
@ -900,7 +900,7 @@ rip_rte_better(struct rte *new, struct rte *old)
|
|||
|
||||
/*
|
||||
* rip_rte_insert - we maintain linked list of "our" entries in main
|
||||
* routing table, so that we can timeout them correctly. rip_timer
|
||||
* routing table, so that we can timeout them correctly. rip_timer()
|
||||
* walks the list.
|
||||
*/
|
||||
static void
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ code is isolated in a small set of modules:
|
|||
<descrip>
|
||||
<tagp><tt/config.h/</tagp> is a header file with configuration information,
|
||||
definition of the standard set of types and so on.
|
||||
<tagp/Startup module/ controls BIRD startup. Common for a family of OS'es (e.g.,
|
||||
<tagp/Startup module/ controls BIRD startup. Common for a family of OS's (e.g.,
|
||||
for all Unices).
|
||||
<tagp/Logging module/ manages the system logs. [per OS family]
|
||||
<tagp/IO module/ gives an implementation of sockets, timers and the
|
||||
|
|
|
|||
|
|
@ -888,7 +888,7 @@ sk_send(sock *s, unsigned len)
|
|||
* @addr: IP address to send the packet to
|
||||
* @port: port to send the packet to
|
||||
*
|
||||
* This is a sk_send() replacement for connectionless packet sockets
|
||||
* This is a sk_send() replacement for connection-less packet sockets
|
||||
* which allows destination of the packet to be chosen dynamically.
|
||||
*/
|
||||
int
|
||||
|
|
|
|||
|
|
@ -16,14 +16,14 @@
|
|||
* The whole kernel synchronization is a bit messy and touches some internals
|
||||
* of the routing table engine, because routing table maintenance is a typical
|
||||
* example of the proverbial compatibility between different Unices and we want
|
||||
* to keep the overhead of our krt business as low as possible and avoid maintaining
|
||||
* to keep the overhead of our KRT business as low as possible and avoid maintaining
|
||||
* a local routing table copy.
|
||||
*
|
||||
* The kernel syncer can work in three different modes (according to system config header):
|
||||
* Either with a single routing table and single KRT protocol [traditional Unix]
|
||||
* or with many routing tables and separate krt protocols for all of them
|
||||
* or with many routing tables and separate KRT protocols for all of them
|
||||
* or with many routing tables, but every scan including all tables, so we start
|
||||
* separate krt protocols which cooperate with each other [Linux 2.2].
|
||||
* separate KRT protocols which cooperate with each other [Linux 2.2].
|
||||
* In this case, we keep only a single scan timer.
|
||||
*
|
||||
* We use FIB node flags to keep track of route synchronization status. We also
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ vlog(int class, char *msg, va_list args)
|
|||
* prepended (%L_DEBUG to %L_BUG, see |lib/birdlib.h|)
|
||||
*
|
||||
* This function formats a message according to the format string @msg
|
||||
* and writes it to the corresponding logfile (as specified in the
|
||||
* and writes it to the corresponding log file (as specified in the
|
||||
* configuration). Please note that the message is automatically
|
||||
* formatted as a full line, no need to include |\n| inside.
|
||||
*/
|
||||
|
|
|
|||
Loading…
Reference in a new issue