bird - Bird routing daemon

Age	Commit message (Collapse)	Author
1999-03-26	Moved to a much more systematic way of configuring kernel protocols.	Martin Mares
	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.
1999-03-24	Removed our declaration of RTPROT_BIRD since Alexey has assigned	Martin Mares
	us a real protocol number in 2.2.4 kernel.
1999-03-04	Fixed processing of !krt_capable() routes. Converted device route decisions	Martin Mares
	to the krt_capable mechanism as well.
1999-03-04	KRT: Implemented asynchronous route / interface state notifications	Martin Mares
	(via Netlink). Tweaked kernel synchronization rules a bit. Discovered locking bug in kernel Netlink :-) Future plans: Hunt all the bugs and solve all the FIXME's.
1999-03-04	Although there are still heaps of FIXME's, Netlink works.	Martin Mares
	To build BIRD with Netlink support, just configure it with ./configure --with-sysconfig=linux-21 After it will be tested well enough, I'll probably make it a default for 2.2 kernels (and rename it to linux-22 :)).
1999-03-04	Converted some mb_alloc/bzero pairs to mb_allocz.	Martin Mares

1999-03-03	Netlink scans routes...	Martin Mares

1999-03-03	Rewrote the kernel syncer. The old layering was horrible.	Martin Mares
	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.