All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, Florian Westphal <fw@strlen.de>,
	netfilter-devel@vger.kernel.org
Subject: Re: [nft PATCH v2 0/4] xt: Implement dump and restore support
Date: Fri, 18 Nov 2022 11:11:42 +0100	[thread overview]
Message-ID: <Y3daXmuU0Nsyeij6@salvia> (raw)
In-Reply-To: <Y3dUxJZ6J4mg/KNh@orbyte.nwl.cc>

Merging threads.

On Fri, Nov 18, 2022 at 10:55:04AM +0100, Phil Sutter wrote:
[...]
> > I think this more or less a summary of what we discussed in the NFWS.
>
> Pablo, I think you're mixing up two things here:
>
> This "support dump and load of compat expression" feature is to sanitize
> the current situation with up to date iptables and nftables.

OK, then the problem we discuss is mixing iptables-nft and nftables.

On Fri, Nov 18, 2022 at 10:47:48AM +0100, Phil Sutter wrote:
[...]
> > At this time I'd rather like a time machine to prevent nft_compat.c from
> > getting merged :-(
>
> If you do, please convince Pablo to not push iptables commit 384958620a.
> I think it opened the can of worms we're trying to confine here.

It could be worst, if iptables-nft would not be in place, then old
iptables-legacy and new nftables rules would have no visibility each
other.

With iptables-nft we have a way to move forward:

- Replace nft_compat by native expressions from iptables-nft.
- Extend iptables-nft to understand more complex expressions, worst
  case dump a native representation.

Why don't we just move ahead this path instead of spinning around the
compat layer? This only requires userspace updates on iptables-nft.

  reply	other threads:[~2022-11-18 10:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-17 17:45 [nft PATCH v2 0/4] xt: Implement dump and restore support Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 1/4] xt: Delay libxtables access until translation Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 2/4] xt: Implement dump and restore support Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 3/4] xt: Put match/target translation into own functions Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 4/4] xt: Detect xlate callback failure Phil Sutter
2022-11-17 21:13 ` [nft PATCH v2 0/4] xt: Implement dump and restore support Florian Westphal
2022-11-18  9:40   ` Pablo Neira Ayuso
2022-11-18  9:55     ` Phil Sutter
2022-11-18  9:47   ` Phil Sutter
2022-11-18 10:11     ` Pablo Neira Ayuso [this message]
2022-11-18 10:42       ` Phil Sutter
2022-11-18 11:46         ` Florian Westphal
2022-11-18 12:12           ` Phil Sutter
2022-11-18 12:18             ` Pablo Neira Ayuso
2022-11-18 12:24               ` Phil Sutter
2022-11-18 13:34                 ` Florian Westphal
2022-11-18 14:10                   ` Pablo Neira Ayuso
2022-11-18 14:52                     ` Phil Sutter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3daXmuU0Nsyeij6@salvia \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.