*/
/**
- * 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.
* 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
/**
* 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.
* 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
* 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
* 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
* 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.
*/
* 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
* 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
/**
* 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.
* 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
*/
* @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
*/
/**
- * 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.
*
* 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 }
*
* 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 }
* 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)
*
* 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
* 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)
* 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
*
* 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)
* 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
* 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
* @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 *
* 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)
/**
* 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
/**
* 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.
*/
/**
* 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
*
* 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
* 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; }
* 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
* 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.
*
* 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.
*
*
* 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.
*/
/*
* 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
<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
* @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
* 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
* 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.
*/
projects / thirdparty / bird.git / commitdiff
