Jerry/bird
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

Spelling fixes to progdoc.

Browse source
This commit is contained in:
Martin Mares 2000-06-07 12:29:08 +00:00
parent e403aa89e5
commit 2e9b24211a
18 changed files with 46 additions and 46 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
conf/cf-lex.l
View file

@ -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

8
conf/conf.c
View file

@ -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

6
filter/filter.c
View file

@ -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
*/

2
lib/checksum.c
View file

@ -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
View file

@ -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 }

2
lib/xmalloc.c
View file

@ -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)

2
nest/cli.c
View file

@ -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

2
nest/proto-hooks.c
View file

@ -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)

4
nest/proto.c
View file

@ -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)

12
nest/rt-attr.c
View file

@ -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

2
nest/rt-dev.c
View file

@ -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.
*/

6
nest/rt-table.c
View file

@ -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; }

4
proto/bgp/bgp.c
View file

@ -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

12
proto/rip/rip.c
View file

@ -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

2
sysdep/sysdep.sgml
View file

@ -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

2
sysdep/unix/io.c
View file

@ -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

6
sysdep/unix/krt.c
View file

@ -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

2
sysdep/unix/log.c
View file

@ -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.
*/