On Wed, Apr 10, 2002 at 02:43:57PM +0200, Harald Welte wrote:
> > Yes, but how do you know at runtime that a particular feature
> > (provided by a patch-o-matic module) is usable?
> by telling the user about the prerequisites and let him apply
> the necessarry patches. If you tell him to apply a patch which is
> already in the kernel, patch-o-matic will detect that it is already
> applied.
I said at runtime. A generic script cannot make any assumption about
the kernel source path or any other thing like that.
This kind of information has to be totally distribution independant.
That's why /proc is good.
> > > > 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?
> 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).
> > > 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)
> find /lib/modules/`uname -r`/kernel/net/ipv4/netfilter -name ipt_XXXX.o
Kinda hacky. But since it should be the same path everywhere, this
could do the job... :-/
> > 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, at least not for me. What is the purpose of a modular kernel, if
> the kernel image needs to know which modules are there? People should be
> able to compile new kernel modules seperately.
> 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. :-(
> > > 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.
> There is no 'api'. It's just some structures.
I know the word was not exactly the right one. I just talk about the
command line options syntax of userspace netfilter modules.
> > 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?
> I was suggesting to add versioning to 2.5.x - but right now I have
> different, more basic stuff on my 2.5.x todo list. Like abstracting
> ip_tables into pkt_tables, creating new netlink-based userspace interface,
> etc.
Userspace versioning wouldn't have any impact on the kernel in the
first step.
But there are two kinds of versioning:
- about kernelspace/userspace structures (which doesn't necessarily
imply any userspace option syntax changes)
- about userspace options syntax changes (which have great chance to
imply kernelspace/userspace structure changes, but not always
necessarily either)
Here I'm more concerned with option syntax versioning (structure versioning
could already be achieved by comparing kernel version with iptables
version, though it's far from being perfect).
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
What do you think?
RV
--
_
(°= Hervé Eychenne
//)
v_/_ WallFire project: http://www.wallfire.org/
