On Thursday 2010-03-25 13:43, Jozsef Kadlecsik wrote: >> >>> >> >>> I'm not really convinced of removing state though, I has never >> >>> caused any maintenance overhead, it requires a lot less memory >> >>> than xt_conntrack >> >> And yet, you proposed removing xt_NOTRACK in favor of xt_CT where the >> same argument about memory tradeoff would hold. > >Just my thoughts: xt_NOTRACK is not so widely used than xt_state. So >it'll bite less (and hopefully more experienced) users. Well that's why we would have a warning messages. It is not rocket science to switch "-m state --state" to "-m conntrack --ctstate" (well, a necessary prerequisite is to know how to use a text editor). And users who _do write_ their own surely are of the more experienced category than those who don't do it at all but are fed by the distro's generator. >> >>> and it seems more intuitive to write "-m state" >> >>> than "-m conntrack --ctstate" to me. >> >> >> >> I oppose the removal of xt_state, *unless* the userspace "-m state" is >> >> kept working and the conntrack module automatically supports it. >> > >> >Yes, that would be acceptable. >> > >> >> It's such a basic match that it's simply overkill to remove it. >> > >> >Agreed. >> >> So what now? Should xt_conntrack be perhaps rebranded as a new >> xt_state rev and let's obsolete xt_conntrack.c instead? > >That's much more acceptable, also because of the usage patterns. And the >migration can be made easier with module aliasing. > >Best regards, >Jozsef >- >E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx >PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt >Address : KFKI Research Institute for Particle and Nuclear Physics > H-1525 Budapest 114, POB. 49, Hungary > -- 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
