Jerry/bird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
bird/sysdep/unix/krt.h

127 lines
3.2 KiB
C
Raw Normal View History

Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
/*
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
* BIRD -- UNIX Kernel Route Syncer
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
*
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
* (c) 1998--1999 Martin Mares <mj@ucw.cz>
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
#ifndef _BIRD_KRT_H_
#define _BIRD_KRT_H_
Kernel route syncer supports multiple tables. 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. :)
1999-08-04 03:33:22 +08:00
struct config;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
struct krt_config;
struct krt_proto;
Moved to a much more systematic way of configuring kernel protocols. 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-27 05:44:38 +08:00
struct kif_config;
struct kif_proto;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
#include "lib/krt-scan.h"
#include "lib/krt-set.h"
Hopefully finished kernel syncer (krt) rewrite: o Interface syncing is now a part of krt and it can have configurable parameters. Actually, the only one is scan rate now :) o Kernel routing table syncing is now synchronized with interface syncing (we need the most recent version of the interface list to prevent lots of routes to non-existent destinations from appearing). Instead of its own timer, we just check if it's route scan time after each iface list scan. o Syncing of device routes implemented. o CONFIG_AUTO_ROUTES should control syncing of automatic device routes. o Rewrote krt_remove_route() to really remove routes :) o Better diagnostics. o Fixed a couple of bugs.
1998-12-09 02:37:58 +08:00
#include "lib/krt-iface.h"
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
KRF_* flags moved to krt.h as they are internal to kernel syncer, fib->pad0,pad1 renamed to x0,x1 and in case of struct net x0 is reserved for kernel syncing as well.
1998-12-07 18:15:42 +08:00
/* Flags stored in net->n.flags */
More changes to the kernel syncer. o Now compatible with filtering. o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS systems (on the others it's impossible to get it semantically correct). o Learning now stores all of its routes in a separate fib and selects the ones the kernel really uses for forwarding packets. o Better treatment of CONFIG_AUTO_ROUTES ports. o Lots of internal changes.
1999-04-03 21:05:18 +08:00
#define KRF_VERDICT_MASK 0x0f
Rewritten kernel syncer. Now uses the rta trickery I've introduced yesterday and does things "the right way". Few things are still missing (device routes etc.), I'll add them later in the evening.
1998-12-09 00:20:13 +08:00
#define KRF_CREATE 0 /* Not seen in kernel table */
KRF_* flags moved to krt.h as they are internal to kernel syncer, fib->pad0,pad1 renamed to x0,x1 and in case of struct net x0 is reserved for kernel syncing as well.
1998-12-07 18:15:42 +08:00
#define KRF_SEEN 1 /* Seen in kernel table during last scan */
#define KRF_UPDATE 2 /* Need to update this entry */
Rewritten kernel syncer. Now uses the rta trickery I've introduced yesterday and does things "the right way". Few things are still missing (device routes etc.), I'll add them later in the evening.
1998-12-09 00:20:13 +08:00
#define KRF_DELETE 3 /* Should be deleted */
More changes to the kernel syncer. o Now compatible with filtering. o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS systems (on the others it's impossible to get it semantically correct). o Learning now stores all of its routes in a separate fib and selects the ones the kernel really uses for forwarding packets. o Better treatment of CONFIG_AUTO_ROUTES ports. o Lots of internal changes.
1999-04-03 21:05:18 +08:00
#define KRF_IGNORE 4 /* To be ignored */
#define KRF_INSTALLED 0x80 /* This route should be installed in the kernel */
/* Whenever we recognize our own routes, we allow learing of foreign routes */
#ifdef CONFIG_SELF_CONSCIOUS
#define KRT_ALLOW_LEARN
#endif
KRF_* flags moved to krt.h as they are internal to kernel syncer, fib->pad0,pad1 renamed to x0,x1 and in case of struct net x0 is reserved for kernel syncing as well.
1998-12-07 18:15:42 +08:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
/* krt.c */
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
extern struct protocol proto_unix_kernel;
Synced kernel interface to new interface.
1999-02-06 05:38:50 +08:00
struct krt_config {
struct proto_config c;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
struct krt_set_params set;
struct krt_scan_params scan;
int persist; /* Keep routes when we exit */
Moved to a much more systematic way of configuring kernel protocols. 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-27 05:44:38 +08:00
int scan_time; /* How often we re-scan routes */
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
int learn; /* Learn routes from other sources */
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
};
Synced kernel interface to new interface.
1999-02-06 05:38:50 +08:00
struct krt_proto {
struct proto p;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
struct krt_set_status set;
struct krt_scan_status scan;
struct krt_if_status iface;
More changes to the kernel syncer. o Now compatible with filtering. o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS systems (on the others it's impossible to get it semantically correct). o Learning now stores all of its routes in a separate fib and selects the ones the kernel really uses for forwarding packets. o Better treatment of CONFIG_AUTO_ROUTES ports. o Lots of internal changes.
1999-04-03 21:05:18 +08:00
#ifdef KRT_ALLOW_LEARN
struct rtable krt_table; /* Internal table of inherited routes */
Kernel route syncer supports multiple tables. 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. :)
1999-08-04 03:33:22 +08:00
#endif
pool *krt_pool; /* Pool used for common krt data */
timer *scan_timer;
#ifdef CONFIG_ALL_TABLES_AT_ONCE
node instance_node; /* Node in krt instance list */
More changes to the kernel syncer. o Now compatible with filtering. o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS systems (on the others it's impossible to get it semantically correct). o Learning now stores all of its routes in a separate fib and selects the ones the kernel really uses for forwarding packets. o Better treatment of CONFIG_AUTO_ROUTES ports. o Lots of internal changes.
1999-04-03 21:05:18 +08:00
#endif
Synced kernel interface to new interface.
1999-02-06 05:38:50 +08:00
};
extern struct proto_config *cf_krt;
Kernel route syncer supports multiple tables. 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. :)
1999-08-04 03:33:22 +08:00
extern pool *krt_pool;
Kernel syncer is now configurable. It will probably need some more options, but at least basic tuning is possible now.
1998-12-07 01:40:42 +08:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
#define KRT_CF ((struct krt_config *)p->p.cf)
void krt_got_route(struct krt_proto *p, struct rte *e);
KRT: Implemented asynchronous route / interface state notifications (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-05 02:36:18 +08:00
void krt_got_route_async(struct krt_proto *p, struct rte *e, int new);
/* Values for rte->u.krt_sync.src */
#define KRT_SRC_UNKNOWN -1 /* Nobody knows */
#define KRT_SRC_BIRD 0 /* Our route (not passed in async mode) */
#define KRT_SRC_REDIRECT 1 /* Redirect route, delete it */
#define KRT_SRC_ALIEN 2 /* Route installed by someone else */
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
Moved to a much more systematic way of configuring kernel protocols. 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-27 05:44:38 +08:00
extern struct protocol proto_unix_iface;
struct kif_config {
struct proto_config c;
struct krt_if_params iface;
int scan_time; /* How often we re-scan interfaces */
};
struct kif_proto {
struct proto p;
struct krt_if_status iface;
};
extern struct proto_config *cf_kif;
#define KIF_CF ((struct kif_config *)p->p.cf)
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
/* krt-scan.c */
Kernel route syncer supports multiple tables. 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. :)
1999-08-04 03:33:22 +08:00
void krt_scan_preconfig(struct config *);
void krt_scan_postconfig(struct krt_config *);
void krt_scan_construct(struct krt_config *);
void krt_scan_start(struct krt_proto *, int);
void krt_scan_shutdown(struct krt_proto *, int);
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
void krt_scan_fire(struct krt_proto *);
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
/* krt-set.c */
Kernel route syncer supports multiple tables. 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. :)
1999-08-04 03:33:22 +08:00
void krt_set_construct(struct krt_config *);
void krt_set_start(struct krt_proto *, int);
void krt_set_shutdown(struct krt_proto *, int);
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
int krt_capable(rte *e);
More changes to the kernel syncer. o Now compatible with filtering. o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS systems (on the others it's impossible to get it semantically correct). o Learning now stores all of its routes in a separate fib and selects the ones the kernel really uses for forwarding packets. o Better treatment of CONFIG_AUTO_ROUTES ports. o Lots of internal changes.
1999-04-03 21:05:18 +08:00
void krt_set_notify(struct krt_proto *x, net *net, rte *new, rte *old);
Use traditional Unix route/iface interface only when CONFIG_NETLINK is not defined. Also moved declarations of Unix iface logic to krt.h.
1999-03-02 03:05:58 +08:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
/* krt-iface.c */
Use traditional Unix route/iface interface only when CONFIG_NETLINK is not defined. Also moved declarations of Unix iface logic to krt.h.
1999-03-02 03:05:58 +08:00
Kernel route syncer supports multiple tables. 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. :)
1999-08-04 03:33:22 +08:00
void krt_if_construct(struct kif_config *);
Moved to a much more systematic way of configuring kernel protocols. 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-27 05:44:38 +08:00
void krt_if_start(struct kif_proto *);
void krt_if_shutdown(struct kif_proto *);
Hopefully finished kernel syncer (krt) rewrite: o Interface syncing is now a part of krt and it can have configurable parameters. Actually, the only one is scan rate now :) o Kernel routing table syncing is now synchronized with interface syncing (we need the most recent version of the interface list to prevent lots of routes to non-existent destinations from appearing). Instead of its own timer, we just check if it's route scan time after each iface list scan. o Syncing of device routes implemented. o CONFIG_AUTO_ROUTES should control syncing of automatic device routes. o Rewrote krt_remove_route() to really remove routes :) o Better diagnostics. o Fixed a couple of bugs.
1998-12-09 02:37:58 +08:00
Moved to a much more systematic way of configuring kernel protocols. 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-27 05:44:38 +08:00
void krt_if_scan(struct kif_proto *);
void krt_if_io_init(void);
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-04 03:49:56 +08:00
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 20:50:43 +08:00
#endif
Reference in a new issue Copy permalink