All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Florian Westphal <fw@strlen.de>
Cc: "Thomas Haller" <thaller@redhat.com>,
	netfilter-devel@vger.kernel.org,
	"Maciej Żenczykowski" <zenczykowski@gmail.com>
Subject: Re: [PATCH v2 nft] parser: tcpopt: fix tcp option parsing with NUM + length field
Date: Wed, 6 Dec 2023 15:19:58 +0100	[thread overview]
Message-ID: <ZXCDDgEhAV3KOCwt@orbyte.nwl.cc> (raw)
In-Reply-To: <20231206120447.GG8352@breakpoint.cc>

On Wed, Dec 06, 2023 at 01:04:47PM +0100, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > Thomas Haller <thaller@redhat.com> wrote:
> > > On Wed, 2023-12-06 at 12:38 +0100, Florian Westphal wrote:
> > > > Thomas Haller <thaller@redhat.com> wrote:
> > > > > Hi Florian,
> > > > > 
> > > > > On Tue, 2023-12-05 at 12:56 +0100, Florian Westphal wrote:
> > > > > >  .../packetpath/dumps/tcp_options.nft          | 14 +++++++
> > > > > 
> > > > > is there a reason not to also generate a .json-nft file?
> > > > 
> > > > Yes, I am not adding more one-line monsters.
> > > > 
> > > > I'll add one once there is a solution in place that has human
> > > > readable
> > > > json dumps that don't fail validation because of identical but
> > > > differently formatted output.
> > > > 
> > > 
> > > What about the "[PATCH nft 0/2] pretty print .json-nft files" patches?
> > 
> > I'm fine with that. Phil? Pablo? This is re:
> > 
> > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20231124124759.3269219-3-thaller@redhat.com/

What I don't like is that we'll still get these huge patches/mails if
the dumps are converted. Those that remain are still hard to handle in
case of errors.

> What about making it so we NEVER compare json-nft at all?
> 
> Instead, feed the json-nft file to nft, then do a normal list-ruleset,
> then compare that vs. normal .nft file.
> 
> This avoids any and all formatting issues and also avoids breakage when
> the json-nft file is formatted differently.

We may hide problems because nft might inadvertently sanitize the input.
Also, conversion from standard syntax to JSON may be symmetrically
broken, so standard->JSON->standard won't detect the problem.

> Eg. postprocessing via json_pp won't match what this patch above
> expects.

Python natively supports JSON. Converting stuff into comparable strings
(which also look pretty when printed) is a simple matter of:

| import json
| 
| json.dumps(json.loads(<dump as string>), \
| 	   sort_keys = True, indent = 4, \
| 	   separators = (',', ': '))

We rely upon Python for the testsuite already, so I don't see why
there's all the fuss. JSON dump create, load and compare have not been a
problem in the 5 years tests/py does it.

Cheers, Phil

  parent reply	other threads:[~2023-12-06 14:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 11:56 [PATCH v2 nft] parser: tcpopt: fix tcp option parsing with NUM + length field Florian Westphal
2023-12-05 12:07 ` Pablo Neira Ayuso
2023-12-05 12:20   ` Florian Westphal
2023-12-05 12:50     ` Pablo Neira Ayuso
2023-12-05 13:14       ` Florian Westphal
2023-12-05 14:10         ` Pablo Neira Ayuso
2023-12-06  7:58 ` Thomas Haller
2023-12-06 11:38   ` Florian Westphal
2023-12-06 11:50     ` Thomas Haller
2023-12-06 11:59       ` Florian Westphal
2023-12-06 12:04         ` Florian Westphal
2023-12-06 12:09           ` Thomas Haller
2023-12-06 12:16             ` Florian Westphal
2023-12-06 13:22               ` Thomas Haller
2023-12-06 13:24                 ` Florian Westphal
2023-12-06 14:56                   ` Thomas Haller
2023-12-06 14:19           ` Phil Sutter [this message]
2023-12-06 15:12             ` Thomas Haller

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=ZXCDDgEhAV3KOCwt@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=thaller@redhat.com \
    --cc=zenczykowski@gmail.com \
    /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.