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? That makes a lot of sense to me. And don't worry about breaking the API for this or other netfilter stuff. I doubt anyone besides me has used it. There's no publicly available programs besides the test ones in libnl. - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
