Jerry/bird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
bird/sysdep/linux/netlink/krt-set.h

28 lines
737 B
C
Raw Normal View History

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 Netlink Route Syncer -- Dummy Include File
*
Kernel route syncer now supports dynamic reconfiguration. Also it doesn't depend on the startup counter hack now and uses a zero-time timer instead to make itself scheduled after normal protocol startup.
2000-01-18 18:39:30 +08:00
* (c) 1998--2000 Martin Mares <mj@ucw.cz>
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
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
#ifndef _BIRD_KRT_SET_H_
#define _BIRD_KRT_SET_H_
/*
* We don't have split iface/scan/set parts. See krt-scan.h.
*/
struct krt_set_params {
};
struct krt_set_status {
};
Marked unused parameters in sysdep code as such.
2004-06-05 17:11:07 +08:00
static inline void krt_set_construct(struct krt_config *c UNUSED) { };
static inline void krt_set_start(struct krt_proto *p UNUSED, int first UNUSED) { };
static inline void krt_set_shutdown(struct krt_proto *p UNUSED, int last UNUSED) { };
static inline int krt_set_params_same(struct krt_set_params *o UNUSED, struct krt_set_params *n UNUSED) { return 1; }
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
#endif
Reference in a new issue Copy permalink