Re: [Nftables RFC] High level library proposal

[Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>]

Hi Eric and Pablo,
>>> I don't get why you may need something different than libmnl or libnl.
>> I don't think Tomasz need it but future application developers will
>> really love to avoid to learn how netlink messages are build.

I actually need this flexibility. But indeed, it's thought to hide 
netlink IOs anyway.

> I was referring to the driver switch that he wants to introduce to
> select libnl or libmnl in runtime, it makes no sense to me.

It's easy to support it. Moreover that it won't affect all devs:
most will just initiate the library to use libnl or libmnl, and won't 
have to provide their own driver implementation.
They will just call nft_init() with NULL as the nl driver and that's it.

If it does not make sense to you to bring this little flexibility then 
ok, let's use libnl.
But then no need to use limnl/libnftables: let's use instead 
libnl-nftables which already does everything on this level, afaik.

My point of using libmnl/libnftables was especially to bring this 
possibility of using something else than
libmnl/libnl to discuss with netlink: since libnftables it dedicated on 
parsing/building nftables nlh (it's perfect for that),
and since libnftables has a dependency over libmnl, let's use libmnl as 
the default one for netlink conversation.

We could solve it another way, like exposing core functions, the fds and 
so on, like libdbus does but I don't like it much.
Instead, providing a structure which tells what subset of functions and 
their signatures is required is nicer. As I said, I tried
a quick PoC on that.

And you can see that feature as being part of a lower level access in 
the API.

>> We definitely need different level of abstractions.
> Nobody said here that we don't need high level abstractions.
>
> My point is that the library should provide different level of
> abstractions, so you can switch to the level you want. Think of it as
> an elevator that takes you to the 1st floor or 9th floor. Depending
> where you get, you see more or less details. If designed carefully,
> that should be possible.

I am not against such different levels, but indeed it requires to be 
careful: if we propose too much things
without good reasons, many devs will just miss-use the API for sure. I 
guess we should provide this different levels
during the lib implementation. It is easier to solve this from top level 
to bottom, incrementally.


Br,

Tomasz