aboutsummaryrefslogtreecommitdiffstats
path: root/net/ipv6
diff options
context:
space:
mode:
authorTom Tucker <tom@opengridcomputing.com>2006-07-30 23:43:36 -0400
committerDavid S. Miller <davem@sunset.davemloft.net>2006-08-02 16:38:21 -0400
commit8d71740c56a9058acc4378504a356d543ff1308b (patch)
treef8be30892b75e7194b121d76adb9847d069f1759 /net/ipv6
parent792d1932e319ff8ba01361e7d151b1794c55c31f (diff)
[NET]: Core net changes to generate netevents
Generate netevents for: - neighbour changes - routing redirects - pmtu changes Signed-off-by: Tom Tucker <tom@opengridcomputing.com> Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv6')
-rw-r--r--net/ipv6/route.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 87c39c978cd0..4b163711f3a8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -53,6 +53,7 @@
53#include <linux/rtnetlink.h> 53#include <linux/rtnetlink.h>
54#include <net/dst.h> 54#include <net/dst.h>
55#include <net/xfrm.h> 55#include <net/xfrm.h>
56#include <net/netevent.h>
56 57
57#include <asm/uaccess.h> 58#include <asm/uaccess.h>
58 59
@@ -742,6 +743,7 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, u32 mtu)
742 dst->metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG; 743 dst->metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG;
743 } 744 }
744 dst->metrics[RTAX_MTU-1] = mtu; 745 dst->metrics[RTAX_MTU-1] = mtu;
746 call_netevent_notifiers(NETEVENT_PMTU_UPDATE, dst);
745 } 747 }
746} 748}
747 749
@@ -1155,6 +1157,7 @@ void rt6_redirect(struct in6_addr *dest, struct in6_addr *saddr,
1155 struct rt6_info *rt, *nrt = NULL; 1157 struct rt6_info *rt, *nrt = NULL;
1156 int strict; 1158 int strict;
1157 struct fib6_node *fn; 1159 struct fib6_node *fn;
1160 struct netevent_redirect netevent;
1158 1161
1159 /* 1162 /*
1160 * Get the "current" route for this destination and 1163 * Get the "current" route for this destination and
@@ -1252,6 +1255,10 @@ restart:
1252 if (ip6_ins_rt(nrt, NULL, NULL, NULL)) 1255 if (ip6_ins_rt(nrt, NULL, NULL, NULL))
1253 goto out; 1256 goto out;
1254 1257
1258 netevent.old = &rt->u.dst;
1259 netevent.new = &nrt->u.dst;
1260 call_netevent_notifiers(NETEVENT_REDIRECT, &netevent);
1261
1255 if (rt->rt6i_flags&RTF_CACHE) { 1262 if (rt->rt6i_flags&RTF_CACHE) {
1256 ip6_del_rt(rt, NULL, NULL, NULL); 1263 ip6_del_rt(rt, NULL, NULL, NULL);
1257 return; 1264 return;
c handler in struct net_device * to handle wireless statistics. * * The initial APIs served us well and has proven a reasonably good design. * However, there is a few shortcommings : * o No events, everything is a request to the driver. * o Large ioctl function in driver with gigantic switch statement * (i.e. spaghetti code). * o Driver has to mess up with copy_to/from_user, and in many cases * does it unproperly. Common mistakes are : * * buffer overflows (no checks or off by one checks) * * call copy_to/from_user with irq disabled * o The user space interface is tied to ioctl because of the use * copy_to/from_user. * * New driver API (2002 -> onward) : * ------------------------------- * The new driver API is just a bunch of standard functions (handlers), * each handling a specific Wireless Extension. The driver just export * the list of handler it supports, and those will be called apropriately. * * I tried to keep the main advantage of the previous API (simplicity, * efficiency and light weight), and also I provide a good dose of backward * compatibility (most structures are the same, driver can use both API * simultaneously, ...). * Hopefully, I've also addressed the shortcomming of the initial API. * * The advantage of the new API are : * o Handling of Extensions in driver broken in small contained functions * o Tighter checks of ioctl before calling the driver * o Flexible commit strategy (at least, the start of it) * o Backward compatibility (can be mixed with old API) * o Driver doesn't have to worry about memory and user-space issues * The last point is important for the following reasons : * o You are now able to call the new driver API from any API you * want (including from within other parts of the kernel). * o Common mistakes are avoided (buffer overflow, user space copy * with irq disabled and so on). * * The Drawback of the new API are : * o bloat (especially kernel) * o need to migrate existing drivers to new API * My initial testing shows that the new API adds around 3kB to the kernel * and save between 0 and 5kB from a typical driver. * Also, as all structures and data types are unchanged, the migration is * quite straightforward (but tedious). * * --- * * The new driver API is defined below in this file. User space should * not be aware of what's happening down there... * * A new kernel wrapper is in charge of validating the IOCTLs and calling * the appropriate driver handler. This is implemented in : * # net/core/wireless.c * * The driver export the list of handlers in : * # include/linux/netdevice.h (one place) * * The new driver API is available for WIRELESS_EXT >= 13. * Good luck with migration to the new API ;-) */ /* ---------------------- THE IMPLEMENTATION ---------------------- */ /* * Some of the choice I've made are pretty controversials. Defining an * API is very much weighting compromises. This goes into some of the * details and the thinking behind the implementation. * * Implementation goals : * -------------------- * The implementation goals were as follow : * o Obvious : you should not need a PhD to understand what's happening, * the benefit is easier maintenance. * o Flexible : it should accommodate a wide variety of driver * implementations and be as flexible as the old API. * o Lean : it should be efficient memory wise to minimise the impact * on kernel footprint. * o Transparent to user space : the large number of user space * applications that use Wireless Extensions should not need * any modifications. * * Array of functions versus Struct of functions * --------------------------------------------- * 1) Having an array of functions allow the kernel code to access the * handler in a single lookup, which is much more efficient (think hash * table here). * 2) The only drawback is that driver writer may put their handler in * the wrong slot. This is trivial to test (I set the frequency, the * bitrate changes). Once the handler is in the proper slot, it will be * there forever, because the array is only extended at the end. * 3) Backward/forward compatibility : adding new handler just require * extending the array, so you can put newer driver in older kernel * without having to patch the kernel code (and vice versa). * * All handler are of the same generic type * ---------------------------------------- * That's a feature !!! * 1) Having a generic handler allow to have generic code, which is more