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
--
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
