On Sun, Apr 14, 2002 at 11:46:15AM +0200, Harald Welte wrote: > On Wed, Apr 10, 2002 at 04:14:05PM +0200, Hervé Eychenne wrote:
> > > I said that this is not covered (assuming that all matches/targets are > > > modules). > > That's a problem (at least for me). > > For me it justifies the need of a /proc mecanism by itself. > > Since we basically seem to agree this would be a good thing, let's add > > it on the TODO list and wait for someone to announce he'll code it (I hate > > duplicate efforts). > well, putting it on TODO is easy - however I doubt anybody will go ahead > implementing it voluntarily. If somebody would have needed the feature > in the past, he'd have implemented it already. Not sure... I personnaly need this feature, but have other prorities for the moment. I'm currently working on a meta application which would use netfilter as a backend. There are many applications based on netfilter: generic scripts, direct GUI transposition of iptables, etc... But mine is somewhat more ambitious, and I need to know what netfilter modules are present on a system in order to generate an idiomatic script, with maximum efficiency. > > > I, for example, regularly just rebuild kernel modules after reconfiguration, > > > and not the kernel image itself (like 'make modules > > > SUBDIRS=net/ipv4/netfilter'). > > I fear you're right. That's the problem with modules: never knowing > > exactly at runtime what features are potentially available. :-( > Well. If you have the /proc interface for currently-loaded modules and > statically compiled in matches/targets _AND_ the /lib/modules/`uname -r`/ > stuff, you have all the functionality you need. Yes, you're right. > > Userspace versioning wouldn't have any impact on the kernel in the > > first step. > but what is the use of userspace versioning if the kernel doesn't have > version information? The userspace would still not know which version > of the structure to use when inserting rules to the kernel. Yes, but that's a different problem. My concern is to know what netfilter modules are available, and with what userspace syntax. This is all I need in order to do what I want. Kernelspace/userspace netfilter compatibility is a netfilter internal problem. My app doesn't have to deal with those problems. :-) > I think versioning should be deferred for 2.5.x and integrated into the > whole new linked-list iptables (in the kernel) and userspace libiptables > design. I guess internal versioning (between kernel and userspace) should. But userspace syntax regarding other upper level applications, even if it is related, is another concern which doesn't necessarily have to wait for so long in theory, as there are no compatibility problems here. RV -- _ (°= Hervé Eychenne //) v_/_ WallFire project: http://www.wallfire.org/
