On 18. September 2014 16:31:08 MESZ, Florian Westphal <fw@xxxxxxxxx> wrote: >Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: >> This patch modularizes br_netfilter so it can be >> rmmod'ed, thus, the hooks can be unregistered. > >I see. Yes, that makes sense. > >Another alternative would be to merge both approaches. >I.e, use my patch, but move all the hook registration to >your proposed br_nf_core module. > >The sysctls would still be registered from bridge.ko. > >Then, if call_iptables is set and iptables rules are active, >do the module autoload and print the warning from your patch, telling >people to modprobe br_nf_core if they want the filtering. > >Unfortunately, we'd have to export (from bridge.ko) some hook >to allow br_nf_core to signal that the hooks have been registered. > >Then, in two years or so, we would remove the autoload hook >in the packet procesing path. I believe basically any transition which relies on people reading feature-removal-schedule or kernel messages and a flag day is just kidding ourselves and things will break for everyone except maybe some distributions at flag day. I think taking compatibility seriously means we can't really change the default behaviour, but can only allow people to manually undo the damage and make sure they won't rely on this behaviour for at least nftables. Or we can change it. But then why wait for two years, it won't change anything. Is there a way to make the userspace tools detect that the compat behaviour needs to be activated? -- 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
