On Sunday 2009-05-17 18:12, Pablo Neira Ayuso wrote: >Jan wrote: >>jamal wrote: >>> With this policy, design errors accumulate along time so we learn the >>> lesson from our own mistakes and[...] >> >> With that policy we end up with the same crap that is happening >> in the kernel. > >I didn't say that this was nice, it's functional :) I am saying if we had learnt something then we should not do the same in userspace. >> Just because we magically managed to stuff lots of functions into an >> .so file does not make it public. It just so happens to save a bunch >> of kilobytes in all of the binaries that were previously statically >> linked to xtables.c, and was deemed one way to figure out how to deal >> with intrusive m_ipt. Sorry, but in all efforts that went in so far, >> I discharge libxtables having a stable API. For that, the iptables >> code is not beauty enough yet. > >I think that we should prioritize backward compatibility versus beauty. And put a halt on evolvement. Compatibility is the ultimate killer argument against about anything. Not that I am fuzzing over the smallish int->bool changes, but potential larger changes. >> Now, I had to just think of Xtables-addons that has a similar issue. > >Indeed, actually I think that a stable ABI would make this easier for you. Not really. The currently release cycle of iptables is long enough. -- 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
