show the routing table as exported to the protocol given resp. as returned
from its import control hook.
To get handling of filtered extended attributes right (even in the old
`show route where <filter>' command), the get_route_info hook gets an
attribute list and all protocol specific rte attributes are contained
there as temporary ones. Updated RIP to do that.
Added ea_append() which joins two ea_list's.
All documentation is built in obj/doc (resp. doc/ if you do a stand-alone build).
Use `make docs' to make the whole documentation or `make userdocs' resp.
`make progdocs' for user manual resp. developer's guide.
of calling the protocols manually.
Implemented printing of dynamic attributes in `show route all'.
Each protocol can now register its own attribute class (protocol->attr_class,
set to EAP_xxx) and also a callback for naming and formatting of attributes.
The callback can return one of the following results:
GA_UNKNOWN Attribute not recognized.
GA_NAME Attribute name recognized and put to the buffer,
generic code should format the value.
GA_FULL Both attribute name and value put to the buffer.
Please update protocols generating dynamic attributes to provide
the attr_class and formatting hook.
The changes are just too extensive for lazy me to list them
there, but see the comment at the top of sysdep/unix/krt.c.
The code got a bit more ifdeffy than I'd like, though.
Also fixed a bunch of FIXME's and added a couple of others. :)
definitely gone. Both rte_update() and rte_discard() have an additional
argument telling which table should they modify.
Also, rte_update() no longer walks the whole protocol list -- each table
has a list of all protocols connected to this table and having the
rt_notify hook set. Each protocol can also freely decide (by calling
proto_add_announce_hook) to connect to any other table, but it will
be probably used only by the table-to-table protocol.
The default debugging dumps now include all routing tables and also
all their connections.
version:
EXPORT <filter-spec> for outbound routes (i.e., those announced
by BIRD to the rest of the world).
IMPORT <filter-spec> for inbound routes (i.e., those imported
by BIRD from the rest of the world).
where <filter-spec> is one of:
ALL pass all routes
NONE drop all routes
FILTER <name> use named filter
FILTER { <filter> } use explicitly defined filter
For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes
the kernel protocol, so that you need to add EXPORT ALL to get the previous
configuration of kernel syncer (as usually, see doc/bird.conf.example for
a bird.conf example :)).
whitespace/semicolon rules for whole config file:
o All non-zero amounts of whitespace are equivalent to single space
(aka `all the whitespace has been born equal' ;-)).
o Comments count as whitespace.
o Whitespace has no syntactic signifance (it can only separate lexical
elements).
o Consequence: line ends are no longer treated as `;'s.
o Every declaration must be terminated by an explicit `;' unless
or by a group enclosed in `{' and `}'.
o Nothing is configured automatically. You _need_ to specify
the kernel syncer in config file in order to get it started.
o Syncing has been split to route syncer (protocol "Kernel") and
interface syncer (protocol "Device"), device routes are generated
by protocol "Direct" (now can exist in multiple instances, so that
it will be possible to feed different device routes to different
routing tables once multiple tables get supported).
See doc/bird.conf.example for a living example of these shiny features.
The new kernel syncer is cleanly split between generic UNIX module
and OS dependent submodules:
- krt.c (the generic part)
- krt-iface (low-level functions for interface handling)
- krt-scan (low-level functions for routing table scanning)
- krt-set (low-level functions for setting of kernel routes)
krt-set and krt-iface are common for all BSD-like Unices, krt-scan is heavily
system dependent (most Unices require /dev/kmem parsing, Linux uses /proc),
Netlink substitues all three modules.
We expect each UNIX port supports kernel routing table scanning, kernel
interface table scanning, kernel route manipulation and possibly also
asynchronous event notifications (new route, interface state change;
not implemented yet) and build the KRT protocol on the top of these
primitive operations.
