On Sun, Apr 14, 2002 at 01:02:32AM -0400, Zygo Blaxell wrote: > In article <[EMAIL PROTECTED]>, > Harald Welte <[EMAIL PROTECTED]> wrote: > >On Wed, Apr 10, 2002 at 09:36:05PM -0400, Zygo Blaxell wrote: > >> I think that the user-space modules should provide much richer version > >> information than a simple version number. Simple version numbers are > >> useless if there are multiple maintainers each extending the code in > >> different ways and distributing it before it is officially integrated > >> (i.e. the status quo for netfilter and indeed most of the Linux kernel). > > > >Where did you get this idea from? Please point me to a single occation > >where any part of iptables was modified in different ways by different > >'maintainers'? > > Sure...the module net/ipv4/netfilter/ip_conntrack_standalone.c was > modified in different ways by Gerd Knorr, Henrik Nordstrom, Jay Schulist, > Harald Welte, Jozsef Kadlescik, Rusty Russell, and Various Artists. > Some of these modifications change kernel-to-user communication mechanisms > (note I include renaming or reformatting things under /proc here), > most change internal kernel-to-kernel API's, or cause failure to build, > or cause failures in other patches.
I was explicitly talking about _iptables_, namely iptables extensions (ipt_XXX.o and their respective counterparts libipt_XXX.so and their userspace api exposed via the iptabels commandline utility). btw: The connection tracking changes you have mentioned all occurred sequentialy, whereas your original statement was suggesting that they had been modified at the same time and different versions were distributed at the same time. And please don't refer to some development stages. Code which is under active development (and has not been officially released by submission to the mainstream kernel) is subject to code fluctutation. I don't see anything > In addition to the CVS tree there are other large distributors of > netfilter--the Linux kernel and all of its derivative flavours (some > of which you mostly control) and all the different Linux distributors > who are now packaging this stuff. > > Suppose some Linux distributor is insane enough to package netfilter with > non-default patch/compile options (oops, too late, Red Hat already did > this), and the distro people throw in some of their own patches that > are not in your CVS because they haven't submitted them yet, or their > patches were submitted but you've rejected them. This is a general problem with free software in general. I have to admit that I am not very lucky with the behaviour of distributors with regard to this. > It would not be difficult to implement version checking module by module, > since the extensible part of kernel/userspace communication is just > passing arbitrary struct's back and forth. Add a struct member for > version and check it whenever the struct is received at both ends. Well, that might be suitable if we'd be taliking about 2.5.x - but we certainly cannot make this change during 2.4.x, because it would break all compatibility to old versions of the iptables commandline utility. As already stated (and documented in the devel meeting proceedings), 2.5.x will see a major redesign of the iptables structures anyway - and versioning is definitely a design criteria. > Ah, iptables2 would be the code I never bother to look at as I'm too > busy banging on the parts of netfilter I'm actually trying to use. ;-) :) well, there's a lot of recent work on libiptables, which i haven't committed to CVS yet, since it is not in a state where it even compiles. > I wonder if there has been some thought to what happens to e.g. a GUI > config tool when new options to an iptables module are added. Will there > be a backward-compatible mechanism that can be used if the GUI finds > a data type newer than itself? The GUI can query libiptables about available plugins and their options. Everything behind is covered by libiptables. The Applications _must not_ make any assumption on which options are present and what data types they use. Everything needs to be read via libiptables at runtime. With libiptables (as soon as it is fully implemented) it is possible to write a GUI (or any other application) which doesn't know anything about individual matches/targets, their options, data types or help messges. The application does not need to be modified if a new match/target is written. Please see the README file, it gives some basic idea... > Zygo Blaxell (Laptop) <[EMAIL PROTECTED]> -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
