[RFC] [PATCH] clean up nf_log API

[Harald Welte]

On Thu, May 11, 2006 at 05:36:36PM +1200, Gregor Maier wrote:
> Hi,
> 
> I wrote a patch about 2 month ago, that does something similiar.

mh, I must have missed that, sorry.

> Maybe some of it is usefull. If you are interested I would venture to
> update the patch.

I think we should merge them in some way.

> The patch uses only a modified version of the normal LOG target, but I
> wanted to change this to a NF_LOG target anyway.

Ok, a new LOG target would be fine, yes.

I now actually like the idea that the old LOG target and old ULOG target
just continue to do what the used to do. 

Only NFLOG supersedes all of them, and allows to access the full
flexibility of all backends.

> * Everything uses nf_log.c as logging API (excpect the obsolete ULOG targets)

as indicated, maybe we should modify LOG back to the old syslog-only
behaviour, too.

> * Loggers in nf_log.c are stackable. More than one logger can be registered
>     per PF

I don't like that idea, since it is overkill from my point of view.  If
somebody wants to log a packet twice, he can have multiple rules in the
ruleset for doing so.

> * nf_loginfo struct has been changed. Instead of the type field and the
>     union there is a "backends" field now that contains a bitmask specifing
>     which backends should process/log this packet. 

bitmask is only required if we go for multiple backends.

> * ipt_LOGc and ip6t_LOG.c have been splitted: 
>     * xt_LOG.c  now contains the targets. The targets
>         always use nf_log for logging. These should be the only
>         logging targets. They take care of setting up nf_loginfo for
>         logging to syslog and/or to other backends
>     * ip_log_syslog.c and ip6_log_syslog.c are new and contain the
>         syslog log backends. When these modules are loaded, the syslog
>         backend is registered with nf_log

that makes sense to a certain degree.  However, if we say that LOG
should be just like in old times, and we have a new NFLOG target, then
that change makes a little bit less sense.  Still I like it because it's
clean.

However, we need to make sure that module autoloading works, e.g. if
somebody uses your xt_LOG (or the 'LOG as in old times' target), then
the ip*_log_syslog.ko backend would have to be loaded on demand.  Also,
I'd prefer the names to indicate that they're netfilter related.

> POTENTIAL PROBLEMS / ALTERNATIVE SOLUTION
> * ipt_log_info and ip6t_log_info have been replaced by xt_log_info (which
>     has changed in size). This means iptables must be recompiled and older
>     iptables versions won't work with these changes. 

this is not acceptable.

I'll modify my patch and merge the changes of your patch that I like and
produce a resulting patchset later today.

Thansk!
-- 
- Harald Welte <laforge at netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20060511/665192a7/attachment.pgp