Re: [Nftables RFC] High level library proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux