Hervé Eychenne wrote:
> 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...
Yes? Why should there be an end?
> Yes, but how do you know at runtime that a particular feature
> (provided by a patch-o-matic module) is usable?
For a module to be usable there must be two things:
a) There must be compiled support in the iptables userspace program,
usually as a loadable module.
b) There must be compiled support in the kernel, usually as a loadable
kernel module.
> Well... try to use the module and see if it fails? Ugly hack...
As there is no way of telling which kernel modules are available without
trying to use them there is not many other paths to go.
What userspace iptables modules are available can be queried by
"iptables -m matchname -h" or "iptables -t targetname -h", but this only
tells you if the needed userspace support exists, not if the kernel
supports it.
> 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). ;-)
Probably true.
> Hack. Hack.
> Cannot reasonnably be used in a generic tool.
This problem is not in any way specific to iptables. Same problem exists
for any other subsystem where there is optional components of evolution.
* Drivers
* TC classifiers
* Netfilter modules
* iptables matches
* iptables modules
* filesystems
* networking protocols (IPv4/IPv6/Appletalk/Atm/IrDA/PPP etc)
In all cases the defined method of finding out if a feature is supported
or not is by trying to use it. Call it a hackm but it is how it is done.
> 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. ;-)
If some proc entries are added then you can by a standard method figure
out what is currently supported by the kernel. By looking for modules
you can quess what other features may be provided by loading these
modules. In both cases, if you try to use the feature and it works then
you know.
> 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?
Not really, but you might want to talk to the modutils maintainers to
add an option to modprobe to be able to list the available modules and
their descriptions, plus aliases.
> 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)?
No! This is a totally wrong approach. The list of possibly loadable
modules is a userspace concern, not at all a kernel business.
> 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?
What? I don't get what you are after. When would this "version switch"
be used?
Regards
Henrik
