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. Admittedly, match and target modules do not tend to be modified and distributed concurrently by different maintainers so far. >The netfilter/iptables project has five maintainers, >the core team members. And we have a single point for distributing >code changes: the CVS tree. 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. >> I'm pretty sure iptables already does [kernel/userspace version checking] >> although not everyone patches the version string when they make >> incompatible changes... I wrote that, and it's wrong--I was getting confused by simultaneous problems in kernel- and user-space during a particularly awful hacking session. There are actually no version checks in the kernel-user communication, and only ip_conntrack in the kernel has a recognizable version string at all. There are lots of version strings in user-space, most if not all of which are NETFILTER_VERSION. 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. >> # iptables -m state --option-list >> >> would output a list of: >> >> [...] > >This is basically what libiptables is supposed to export via it's API >to iptables2. Please look at the 'iptables2/libiptables/README' file >in CVS and/or read the respective code. 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. ;-) 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? With the current iptables design, a GUI could always still function if it falls back to asking the user for command-line arguments. Perhaps that is sufficient--if a GUI can't figure out how to ask for an argument, it might just allow the user to insert an arbitrary iptables command line instead of going through the library. Perhaps I'm biased (I do a lot of Tcl/Tk scripting), but it would be nice to have the iptables command-line utility still generate machine-readable text, even if all it's really doing is spitting out what the libiptables library tells it to, without having to link binary modules into the calling process's address space. This might be impractical for things that require special user-space support (e.g. ippool), but for the vast majority of modules it should be useful. There's a big difference in installation, configuration, and reliability between an all-script Tk application and one that is a mixture of script and binary code to load these libraries. I'd much rather write a "pure" Tcl/Perl/Python/whatever script that simply does an exec() through /sbin/iptables, as that's much more likely to continue to work as iptables evolves underneath it or when the script is moved around between machines running different Linux distros. -- Zygo Blaxell (Laptop) <[EMAIL PROTECTED]> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
