Re: (re-send): Convert libnetfilter_queue to not need libnfnetlink]

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

Hi Duncan,

On Fri, Mar 29, 2024 at 08:31:13AM +1100, Duncan Roe wrote:
> Hi Pablo,
> 
> On Mon, Sep 11, 2023 at 09:51:07AM +0200, Pablo Neira Ayuso wrote:
> > On Mon, Sep 11, 2023 at 03:54:25PM +1000, Duncan Roe wrote:
> [SNIP]
> > > libnetfilter_queue effectively supports 2 ABIs, the older being based on
> > > libnfnetlink and the newer on libmnl.
> >
> > Yes, there are two APIs, same thing occurs in other existing
> > libnetfilter_* libraries, each of these APIs are based on libnfnetlink
> > and libmnl respectively.
> >
> [SNIP]
> >
> > libnfnetlink will go away sooner or later. We are steadily replacing
> > all client of this library for netfilter.org projects. Telling that
> > this is not deprecated without providing a compatible "old API" for
> > libmnl adds more confusion to this subject.
> >
> > If you want to explore providing a patch that makes the
> > libnfnetlink-based API work over libmnl, then go for it.
> 
> OK I went for it. But I posted the resultant patchset as a reply to an
> earlier email.
> 
> The Patchwork series is
> https://patchwork.ozlabs.org/project/netfilter-devel/list/?series=399143
> ("Convert nfq_open() to use libmnl").
> 
> The series is "code only" - I kept back the documentation changes for
> spearate review. These documentation changes present the "old API" as
> merely an alternative to the mnl API: both use libmnl.

Thanks for explaining.

> Do you think you might find time to look at it before too long? I know you
> are very busy but I would appreciate some feedback.

This update is large it comes with its own risks and I see chances
that existing applications might break with this "transparent"
approach (where user is not aware that libnfnetlink is not used
anymore).

So far main complains with the new API is that it is too low level
(some users do not want to know about netlink details). The old API is
popular because it provides an easy way for users to receive packets
from the nfnetlink subsystem without dealing with netlink details.

My suggestion is to extend the new API with more functions to make it
ressemble more like the old API. Then, document how to migrate from
the old API to the new API, such documentation would be good to
include a list of items with things that have changed between old and
new APIs.

Would you consider feasible to follow up in this direction? If so,
probably you can make new API proposal that can be discussed.

I hope this does not feel discouraging to you, I think all this work
that you have done will be useful in this new approach and likely you
can recover ideas from this patchset.

Thanks for your patience.