Re: [RFC] [PATCH] clean up nf_log API

[Patrick McHardy <kaber@trash.net>]

Harald Welte wrote:
> On Thu, May 11, 2006 at 08:56:49AM +0200, Patrick McHardy wrote:
> 
> 
>>That all sounds very reasonable. How is the priority of a backend
>>determined?
> 
> 
> statically.  nfnetlink_log overrules ULOG, which overrules LOG.
> 
> We could make that configurable, but I think that's too much
> flexibility.  If a user _wants_ a specific backend, he can chose it. if
> not, we'll fallback on something.


I'm not sure about this. I assume a user would choose the backend
by specifying extra arguments to the NFLOG target, but that isn't
possible for internal logging.

>>>b) reference counting.  We could actually get_module / put_module the
>>>   module that implements a specific backend rather than using our own
>>>   use counter.
>>
>>I guess it depends on whether we want to block unloading while it is
>>in use or do automatic fallback. I tend to prefer the later.
> 
> 
> I agree, I prefer automatic fallback while giving the user the ability
> to unload.  However, if people automatically unload 'unused' modules,
> then there might be a problem (however, for both ULOG and nfnetlink_log,
> userspace listeners would increment the refcount, I think).


Do people still do that? I think distributions stopped the
"rmmod -something" triggered by cron a long time ago.
Anyway, netlink listeners will keep the module pinned.


> Also, there is another unresolved problem:  What if we actually have
> e.g. nfnetlink_log loaded, but it is unable to send a specific packet to
> userspace because there is no listener for this Address family or log
> group?   Should we then also fall back on some other backend?
> 
> At the moment we only fall back if a backend is unbound, but not if it
> e.g. returns an error code because it was unable to log a specific
> packet.


If the user explicitly specifies the backend we shouldn't fall back.
Otherwise I'm not sure .. it probably makes sense as long as we don't
permanently disable the higher priority backend.

BTW, I have a patch queued for 2.6.18 that makes the logging functions
return a status. I guess your patch already includes that, shall
I drop my patch?