On Wed, Feb 05, 2014 at 11:42:47AM +0100, Pablo Neira Ayuso wrote: > On Wed, Feb 05, 2014 at 10:25:48AM +0000, Patrick McHardy wrote: > > Just noticed commit cc70d069 (netfilter: REJECT: separate reusable code). > > That doesn't look like a good idea to me at all. > > > > First of all, it introduces static non-inline functions into a header file, > > which is obviously wrong. But more importantly, it adds a symbol dependency > > of the reject module on IPv6. We've tried hard to get rid of all these in > > x_tables, lets please not re-add them in nftables. > > Well, I think this is working at this moment, we can improve it of > course. Sure. I'd just prefer to have it done right from the beginning instead of having to fix it up afterwards if we already know of these problems. It just takes more time this way. I wonder if we could add something that would break compilation for anything in net/netfilter depending on the ipv6 module. It keeps happening again and again. > > I think we should instead use AF-specific modules for things like that. > > We share basically no code except the boiler plate. I'd suggest to add > > an AF-specific expression type lookup mechanism that takes precedence > > over generic types. > > Yes, this looks like the way to go to me. > > How do you plan to handle this with the inet table? We don't have > family context there. Hmm good question indeed. We do have it at runtime, but this would obviously also mean we'd also have to dispatch at runtime. I guess an NFPROTO_INET specific reject module that dispatches to the IPv4 and IPv6 versions is the only possibility unless we want to add restrictions (which I don't). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
