In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Herv=E9?= Eychenne <[EMAIL PROTECTED]> wrote:
>So, as far as syntax versioning is concerned:
># iptables -m state --version
> and
># iptables -j REJECT --version
>
>would give
>1.0
>the same way --help does already provide information about a particular
>module.
>If noone complains in the next few days, I will try to provide a patch
>in order to add userspace versioning in the next days.
>What versioning scheme should be applied?
>
>upstream modules:
>- 1.0 as a start (1.2.6a)
>- increase major of 1 for option syntax modification
>- increase minor of 0.1 for added options
>
>patch-o-matic modules:
>- 0.10 as a start (1.2.6a)
>- increase minor of 0.1 for option syntax modification
>- increase minor of 0.01 for added options
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).
The iptables user-space module must already implement the entire
user-kernel interface for that module, so all the kernel-space module
needs to do is declare exactly which user-space module version
it supports, and the user-space module version either matches the
kernel-space module version string exactly, or it doesn't.
If you and I modify the foo module version 1.4 in incompatible ways,
I might create "foo-1.4-zb" while you might create "foo-1.4-rv". Later
these might both be merged into "foo-1.5", but in the interim they still
have to work. ;-)
If the user-space and kernel-space modules check the version string, there
is no danger of my user-space module being accidentally used to configure
your kernel-space module (nor any unpredictable consequences that might
arise from such a mixture). I'm pretty sure iptables already does
this, although not everyone patches the version string when they make
incompatible changes...
Back to user-space. The information you get from iptables about a
module should be something like what you get from --help, but more
machine-readable. Perhaps:
# iptables -m state --option-list
would output a list of:
- options and the type and range of their allowable values:
ip, ip/netmask, int, port number, string, multiple-choice,
boolean, etc.
- a list of all tables and chains where it is valid to use the
module,
- a list of module-specific features that a user has to know
about. These are basically a list of arbitrary strings that are
meaningful only to the module and users of the module, but which
are not options or option values. Example: suppose a module
contains a linear list which is replaced by a hash table in
a later version. This change does not change the behavior of
the module, but does change its ability to scale to truly large
numbers of list entries--and this might be something that a GUI
might want to know about. OK, it's not a good example, and I
have no idea how you would use this in real life, but I present
it here for completeness. ;-)
Some examples (note these are not complete lists of options, I just
picked a few extension modules for illustrative purposes):
# Argument is multiple choice
# iptables -j REJECT --option-list
tables mangle filter
chains INPUT OUTPUT FORWARD PREROUTING POSTROUTING
option --reject-with choose icmp-net-unreachable icmp-host-unreachable
icmp-proto-unreachable icmp-net-prohibited icmp-host-prohibited tcp-reset
# Argument is a comma-separated subset from a list of possible values.
# ! is shown wherever an optional ! is permitted.
# iptables -m state --option-list
tables filter
chains INPUT OUTPUT FORWARD PREROUTING POSTROUTING
option ! --state set INVALID ESTABLISHED NEW RELATED
# Argument is an integer
# iptables -j MARK --option-list
tables mangle
chains INPUT OUTPUT FORWARD PREROUTING POSTROUTING
option --set-mark int
# Argument is an integer with optional /mask
# iptables -m mark --option-list
tables mangle
chains INPUT OUTPUT FORWARD PREROUTING POSTROUTING
option ! --mark int
option ! --mark int/mask
# Argument is a MAC address, only valid in some places
# iptables -m mac --option-list
tables mangle filter
chains PREROUTING FORWARD INPUT
option --mac-source ! mac-address
# Argument is either a multiple-choice string or an int from 0..255.
# If there are multiple "option" lines, you can use your choice.
# I've abbreviated this one for clarity.
# iptables -m icmp --option-list
tables ...
chains ...
option --icmp-type ! range 0 255
option --icmp-type ! choose echo-request echo-reply ...
Now all the GUIs have to do is call iptables to find out what options
(and their arguments) are supported by user-space. If new options are
added, the old GUIs will still work (as long as the options they use
are still present).
--
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
