Lennart Poettering <lenn...@poettering.net> wrote: > > To simplify the prototype I modified the API to drop the 'always NULL' > > arguments > > to focus on what is actually used. > > If there's indeed stuff that isn't used I think a patch that removes > support for them altogether would be very welcome.
Great. I will split that from the nftables related work and submit a PR for it. > > 5. this currently replaces the libiptc backend. > > Alternatives are a compile time or run-time switch. > > Ideally, if both backends are compiled in we'd pick the right one > automatically. OK, that is doable. > > If you want to retain the libiptc backend in any case: Do you have > > suggestions > > on how to toggle this? Would a configure switch be enough? > > I'd post this as RFC PR on github, and CC @mbiebl, who's our > downstream Debian maintainer, he might have a perspective on the > future of non-nftables iptables. Will do, thanks. > BTW, is there any perspective of using sd-netlink as library backend > for the interaction with the kernel side of things? I extended sd-netlink with support for nfnetlink for this to work, so instead of RTNETLINK+GENETLINK there is now an nfnetlink backend as well. >From your comments so far I would guess an acceptable solution would be to retain the '--with-libiptc' switch, but build the nfnetlink/nftables backend unconditionally. Then, if nftables initialisation fails (e.g. because kernel was built without nftables support), fall back to libiptc/iptables-classic. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
