Re: libnl netfilter log

[Pablo Neira Ayuso <pablo@netfilter.org>]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> I've added support for netfilter queueing to libnl based on the
>> logging support and would like to suggest a few changes.
>>
>> One of the problems with the netfilter libraries has been adding
>> support for new features, since that often required changing
>> function signatures, for example:
>>
>> extern int nfq_set_verdict(struct nfq_q_handle *qh,
>>                              u_int32_t id,
>>                              u_int32_t verdict,
>>                              u_int32_t data_len,
>>                              unsigned char *buf);
>>
>> extern int nfq_set_verdict_mark(struct nfq_q_handle *qh,
>>                                   u_int32_t id,
>>                                   u_int32_t verdict,
>>                                   u_int32_t mark,
>>                                   u_int32_t datalen,
>>                                   unsigned char *buf);
>>
>> libnl always took an object-centric approach, so this would
>> look something like this:
>>
>> nfnl_queue_msg_set_verdict(pkt, verdict);
>> nfnl_queue_msg_set_mark(pkt, mark);
>> nfnl_queue_msg_send_verdict(pkt);
>>
>> which avoids this problem. The libnl logging support deviates
>> from this scheme, for example with this function:
>>
>> int nfnl_log_set_mode(struct nl_handle *nlh, uint16_t queuenum,
>>                       uint8_t copy_mode, uint32_t copy_range)
>>
>> What I would like to change is make struct nfnl_log the logging
>> instance, so you would have:
>>
>> nfnl_log_set_mode(log, mode);
>> nfnl_log_set_copy_range(log, range);
>> nfnl_log_send_config(log);
>>
>> and add a new struct nfnl_log_message, which represents the
>> actual messages. Similar for queueing, we would have a
>> struct nfnl_queue and nfnl_queue_message.
>>
>> Any objections or suggestions to this API change?
> 
> Looks fine to me. Actually, much better than the current API :)

Hm, wait. Did libnl adopt an API similar to libnetfilter_log? Uh bad :)
Then, instead of changing the API that is something that could break any
existing application, I think that you can introduce the new API that
you propose and put the old one with the __attribute__((deprecated)) thing.

BTW, is libnl website broken? Any CVS or something I can get a working
copy to have a look at current netfilter support?

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers