--- /dev/null
+<!--
+ BIRD Programmer's Guide: Sysdeps
+
+ (c) 2000 Martin Mares <mj@ucw.cz>
+-->
+
+<chapt>System dependent parts
+
+<sect>Introduction
+
+<p>We've tried to make BIRD as portable as possible, but unfortunately
+communication with the network stack differs from one OS to another,
+so we need at least some OS specific code. The good news is that this
+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.,
+for all Unices).
+<tagp/Logging module/ manages the system logs. [per OS family]
+<tagp/IO module/ gives an implementation of sockets, timers and the
+global event queue. [per OS family]
+<tagp/KRT module/ implements the Kernel and Device protocols. This
+is the most arcane part of the system dependent stuff and some
+functions differ even between various releases of a single OS.
+</descrip>
* Can be freely distributed and used under the terms of the GNU GPL.
*/
+/**
+ * DOC: Kernel synchronization
+ *
+ * This system dependent module implements the Kernel and Device protocol,
+ * that is synchronization of interface lists and routing tables with the
+ * OS kernel.
+ *
+ * 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
+ * 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, but every scan including all tables, so we start
+ * 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
+ * attach temporary &rte's to the routing tables, but it cannot harm the rest of
+ * BIRD since table synchronization is an atomic process.
+ *
+ * When starting up, we cheat by looking if there is another
+ * KRT instance to be initialized later and performing table scan
+ * only once for all the instances.
+ */
+
+/*
+ * If you are brave enough, continue now. You cannot say you haven't been warned.
+ */
+
#undef LOCAL_DEBUG
#include "nest/bird.h"
#include "unix.h"
#include "krt.h"
-/*
- * 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
- * a local routing table copy.
- *
- * The kernel syncer can work in three different modes (according to system config header):
- * o Single routing table, single krt protocol. [traditional Unix]
- * o Many routing tables, separate krt protocols for all of them.
- * o Many routing tables, but every scan includes all tables, so we start
- * separate krt protocols which cooperate with each other. [Linux 2.2]
- * In this case, we keep only a single scan timer.
- *
- * The hacky bits:
- * o We use FIB node flags to keep track of route synchronization status.
- * o When starting up, we cheat by looking if there is another kernel
- * krt instance to be initialized later and performing table scan
- * only once for all the instances.
- * o We attach temporary rte's to routing tables.
- *
- * If you are brave enough, continue now. You cannot say you haven't been warned.
- */
-
static int krt_uptodate(rte *k, rte *e);
/*
/*
* BIRD Library -- Logging Functions
*
- * (c) 1998--1999 Martin Mares <mj@ucw.cz>
+ * (c) 1998--2000 Martin Mares <mj@ucw.cz>
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
+/**
+ * DOC: Logging
+ *
+ * The Logging module offers a simple set of functions for writing
+ * messages to system logs and to the debug output.
+ */
+
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
cli_echo(class, buf);
}
+/**
+ * log - log a message
+ * @msg: printf-like formatting string with message class information
+ * 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
+ * configuration). Please note that the message is automatically
+ * formatted as a full line, no need to include |\n| inside.
+ */
void
log(char *msg, ...)
{
va_end(args);
}
+/**
+ * bug - report an internal error
+ * @msg: a printf-like error message
+ *
+ * This function logs an internal error and aborts execution
+ * of the program.
+ */
void
bug(char *msg, ...)
{
abort();
}
+/**
+ * bug - report a fatal error
+ * @msg: a printf-like error message
+ *
+ * This function logs a fatal error and aborts execution
+ * of the program.
+ */
void
die(char *msg, ...)
{
exit(1);
}
+/**
+ * debug - write to debug output
+ * @msg: a printf-like message
+ *
+ * This function formats the message @msg and prints it out
+ * to the debugging output. No newline character is appended.
+ */
void
debug(char *msg, ...)
{
projects / thirdparty / bird.git / commitdiff
