On Wed, Apr 10, 2002 at 10:51:02AM +0200, Harald Welte wrote:
Hi,
> > There's already a lot of modules, and it seems like there will be
> > more and more in future.
> >
> > - some netfilter modules belong to the upstream kernel or iptables
> > distribution
> true. However, most of the common modules are scheduled to become part
> of the kernel at the time we've declared them stable and they don't
> interact with other plans.
Yes, but when some existing modules will go into the kernel, some
other modules will have been created, waiting for "validation".
Seems like a never ending story...
> > - some netfilter modules can be installed through patch-o-matic
> all of the modules not part of the kernel can be installed through
> patch-o-matic
Yes, but how do you know at runtime that a particular feature
(provided by a patch-o-matic module) is usable?
Well... try to use the module and see if it fails? Ugly hack...
> > - netfilter module options can change with time
> generally not true. There have been very few (two?) cases where this
> happened - and we made sure that it is forward- and backwards-compatible
> (i.e. you can use old kernel with new iptables and vice-versa).
By that, I also meant add options to an existing module, not only
modify existing syntax (which must be avoided as much as possible, I
agree).
As the iptables manpage original author, I can tell you that much more
than two options have been added in the past (I know you only talked
about modifications). ;-)
> > All those reasons make it difficult to know what matches or targets
> > are available on the current system, which confuses users and oblige
> > "generic" scripts to use only a minimal subset of existing netfilter
> > functionnalities.
> Go to your kernel source directoty and parse .config - it should tell you
> which matches/targets have been compiled in or compiled as modules
> cat /usr/src/linux/.config | egrep '^CONFIG_IP_NF_MATCH|^CONFIG_IP_NF_TARGET'
Hack. Hack.
Cannot reasonnably be used in a generic tool.
> > What's why I suggest a mechanism which would provide the list of
> > currently available matches and targets, with their API (regarding options)
> > versions. /proc seems to be a good candidate.
> Well, we could only list the currently loaded matches/targets, which can
> be read out by parsing 'lsmod' anyway. (assuming that all matches/targets
> are modules).
Too many assumptions for me here too.
What about statically compiled netfilter modules?
How to recognize netfilter modules by their names?
How to differentiate matches from targets?
Well, I stop here. ;-)
> But having something like /proc/net/ipv4/netfilter/{match,target}_names
> would be a nice contribution, and definitely be welcome :)
I may not have the time to do it myself, so I just talked about the
idea to see if someone would have my time instead of me. ;-)
BTW, what about netfilter modules that have been compiled as kernel
modules, but still not loaded? Is there any other way than trying to
insmod them to see if they are available? (ugly)
Would it be acceptable that this /proc thing should provide a way to inform
that a netfilter module has been compiled as a kernel module (even if not
inserted at the time the cat /proc/net/ipv4/netfilter/{match,target}_names
is done)?
> The kernel modules don't know anything about commandline-options of
> iptables - and this is by design, since this doesn't belong into the kernel.
Yes, but we can assume there's a direct mapping between user-visible
functionnalities brought by a kernel netfilter module and its
userspace counterpart, and so the API of the latter too, I guess.
But I "conceptually" agree that it is not a good thing to store
userspace API version in the kernel even if there's a bijection.
So, why not consider adding an API version switch to every userspace
module, then?
RV
--
_
(°= Hervé Eychenne
//)
v_/_ WallFire project: http://www.wallfire.org/
