1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2: <HTML>
3: <HEAD>
4: <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 1.0.9">
5: <TITLE>BIRD Programmer's Documentation: System dependent parts</TITLE>
6: <LINK HREF="prog-7.html" REL=next>
7: <LINK HREF="prog-5.html" REL=previous>
8: <LINK HREF="prog.html#toc6" REL=contents>
9: </HEAD>
10: <BODY>
11: <A HREF="prog-7.html">Next</A>
12: <A HREF="prog-5.html">Previous</A>
13: <A HREF="prog.html#toc6">Contents</A>
14: <HR>
15: <H2><A NAME="s6">6.</A> <A HREF="prog.html#toc6">System dependent parts</A></H2>
16:
17: <H2><A NAME="ss6.1">6.1</A> <A HREF="prog.html#toc6.1">Introduction</A>
18: </H2>
19:
20: <P>We've tried to make BIRD as portable as possible, but unfortunately
21: communication with the network stack differs from one OS to another,
22: so we need at least some OS specific code. The good news is that this
23: code is isolated in a small set of modules:
24: <P>
25: <DL>
26: <DT><CODE>config.h</CODE><DD><P>is a header file with configuration information,
27: definition of the standard set of types and so on.
28: <DT>Startup module<DD><P>controls BIRD startup. Common for a family of OS's (e.g.,
29: for all Unices).
30: <DT>Logging module<DD><P>manages the system logs. [per OS family]
31: <DT>IO module<DD><P>gives an implementation of sockets, timers and the
32: global event queue. [per OS family]
33: <DT>KRT module<DD><P>implements the Kernel and Device protocols. This
34: is the most arcane part of the system dependent stuff and some
35: functions differ even between various releases of a single OS.
36: </DL>
37: <H2><A NAME="ss6.2">6.2</A> <A HREF="prog.html#toc6.2">Logging</A>
38: </H2>
39:
40: <P>
41: <P>The Logging module offers a simple set of functions for writing
42: messages to system logs and to the debug output. Message classes
43: used by this module are described in <CODE>birdlib.h</CODE> and also in the
44: user's manual.
45: <P>
46: <P><HR><H3>Function</H3>
47: <P><I>void</I>
48: <B>log_commit</B>
49: (<I>int</I> <B>class</B>, <I>buffer *</I> <B>buf</B>) -- commit a log message
50: <P>
51: <H3>Arguments</H3>
52: <P>
53: <DL>
54: <DT><I>int</I> <B>class</B><DD><P>message class information (<I>L_DEBUG</I> to <I>L_BUG</I>, see <CODE>lib/birdlib.h</CODE>)
55: <DT><I>buffer *</I> <B>buf</B><DD><P>message to write
56: </DL>
57: <H3>Description</H3>
58: <P>This function writes a message prepared in the log buffer to the
59: log file (as specified in the configuration). The log buffer is
60: reset after that. The log message is a full line, <B>log_commit()</B>
61: terminates it.
62: <P>The message class is an integer, not a first char of a string like
63: in <B>log()</B>, so it should be written like *L_INFO.
64:
65:
66: <HR><H3>Function</H3>
67: <P><I>void</I>
68: <B>log_msg</B>
69: (<I>const char *</I> <B>msg</B>, <I>...</I> <B>...</B>) -- log a message
70: <P>
71: <H3>Arguments</H3>
72: <P>
73: <DL>
74: <DT><I>const char *</I> <B>msg</B><DD><P>printf-like formatting string with message class information
75: prepended (<I>L_DEBUG</I> to <I>L_BUG</I>, see <CODE>lib/birdlib.h</CODE>)
76: <DT><I>...</I> <B>...</B><DD><P>variable arguments
77: </DL>
78: <H3>Description</H3>
79: <P>This function formats a message according to the format string <B>msg</B>
80: and writes it to the corresponding log file (as specified in the
81: configuration). Please note that the message is automatically
82: formatted as a full line, no need to include <CODE>\n</CODE> inside.
83: It is essentially a sequence of <B>log_reset()</B>, <B>logn()</B> and <B>log_commit()</B>.
84:
85:
86: <HR><H3>Function</H3>
87: <P><I>void</I>
88: <B>bug</B>
89: (<I>const char *</I> <B>msg</B>, <I>...</I> <B>...</B>) -- report an internal error
90: <P>
91: <H3>Arguments</H3>
92: <P>
93: <DL>
94: <DT><I>const char *</I> <B>msg</B><DD><P>a printf-like error message
95: <DT><I>...</I> <B>...</B><DD><P>variable arguments
96: </DL>
97: <H3>Description</H3>
98: <P>This function logs an internal error and aborts execution
99: of the program.
100:
101:
102: <HR><H3>Function</H3>
103: <P><I>void</I>
104: <B>die</B>
105: (<I>const char *</I> <B>msg</B>, <I>...</I> <B>...</B>) -- report a fatal error
106: <P>
107: <H3>Arguments</H3>
108: <P>
109: <DL>
110: <DT><I>const char *</I> <B>msg</B><DD><P>a printf-like error message
111: <DT><I>...</I> <B>...</B><DD><P>variable arguments
112: </DL>
113: <H3>Description</H3>
114: <P>This function logs a fatal error and aborts execution
115: of the program.
116:
117:
118: <HR><H3>Function</H3>
119: <P><I>void</I>
120: <B>debug</B>
121: (<I>const char *</I> <B>msg</B>, <I>...</I> <B>...</B>) -- write to debug output
122: <P>
123: <H3>Arguments</H3>
124: <P>
125: <DL>
126: <DT><I>const char *</I> <B>msg</B><DD><P>a printf-like message
127: <DT><I>...</I> <B>...</B><DD><P>variable arguments
128: </DL>
129: <H3>Description</H3>
130: <P>This function formats the message <B>msg</B> and prints it out
131: to the debugging output. No newline character is appended.
132:
133: <H2><A NAME="ss6.3">6.3</A> <A HREF="prog.html#toc6.3">Kernel synchronization</A>
134: </H2>
135:
136: <P>
137: <P>This system dependent module implements the Kernel and Device protocol,
138: that is synchronization of interface lists and routing tables with the
139: OS kernel.
140: <P>The whole kernel synchronization is a bit messy and touches some internals
141: of the routing table engine, because routing table maintenance is a typical
142: example of the proverbial compatibility between different Unices and we want
143: to keep the overhead of our KRT business as low as possible and avoid maintaining
144: a local routing table copy.
145: <P>The kernel syncer can work in three different modes (according to system config header):
146: Either with a single routing table and single KRT protocol [traditional UNIX]
147: or with many routing tables and separate KRT protocols for all of them
148: or with many routing tables, but every scan including all tables, so we start
149: separate KRT protocols which cooperate with each other [Linux].
150: In this case, we keep only a single scan timer.
151: <P>We use FIB node flags in the routing table to keep track of route
152: synchronization status. We also attach temporary <I>rte</I>'s to the routing table,
153: but it cannot do any harm to the rest of BIRD since table synchronization is
154: an atomic process.
155: <P>When starting up, we cheat by looking if there is another
156: KRT instance to be initialized later and performing table scan
157: only once for all the instances.
158: <P>The code uses OS-dependent parts for kernel updates and scans. These parts are
159: in more specific sysdep directories (e.g. sysdep/linux) in functions krt_sys_*
160: and kif_sys_* (and some others like <B>krt_replace_rte()</B>) and krt-sys.h header file.
161: This is also used for platform specific protocol options and route attributes.
162: <P>There was also an old code that used traditional UNIX ioctls for these tasks.
163: It was unmaintained and later removed. For reference, see sysdep/krt-* files
164: in commit 396dfa9042305f62da1f56589c4b98fac57fc2f6
165: <P>
166: <P>
167: <HR>
168: <A HREF="prog-7.html">Next</A>
169: <A HREF="prog-5.html">Previous</A>
170: <A HREF="prog.html#toc6">Contents</A>
171: </BODY>
172: </HTML>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to prog-6.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc