On Wed, Apr 10, 2002 at 02:06:24PM +0200, 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...
Well, alternatively we can also stop all new development ;)
> 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.
> > > 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).
> How to recognize netfilter modules by their names?
ipt_XXXX
> How to differentiate matches from targets?
matches are lowercase, targets uppercase. This is reliable, since even
iptables does rely on it (for module autoloading).
> > 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
> 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').
> > 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. And the compiled
code doesn't even know about the name of the struct members, since
everything gets compiled into adresses and offsets.
> 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.
> (°= Hervé Eychenne
--
Live long and prosper
- Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
