netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft 3/3,v2] netlink_linearize: skip set element expression in map statement key
Date: Wed, 27 Sep 2023 15:09:53 +0200	[thread overview]
Message-ID: <ZRQpodNr/9aiVI7H@orbyte.nwl.cc> (raw)
In-Reply-To: <ZRQPw+jMI+i9qSyE@calendula>

On Wed, Sep 27, 2023 at 01:19:31PM +0200, Pablo Neira Ayuso wrote:
> Hi Phil,
> 
> On Wed, Sep 27, 2023 at 01:10:09PM +0200, Phil Sutter wrote:
> > Hi Pablo,
> > 
> > On Wed, Sep 27, 2023 at 10:42:36AM +0200, Pablo Neira Ayuso wrote:
> > [...]
> > > Did you ever follow up on your pull request for libjansson or did you
> > > find a way to dynamically allocate the error reporting area that they
> > > complain about?
> > 
> > All done. When there were no technical reasons left to reject it, I was
> > told it's not important enough[1].
> 
> Concern seems to be related to extra memory consumption.
> 
> Would it be possible to revisit your patchset so the extra memory
> consumption for error reporting only happens if some flag is toggle to
> request this? Some sort of opt-in mechanism. Would that be feasible?

You mean eliminate the 'location' pointer field from json_*_t structs?
Because apart from that, the whole thing is already opt-in based on
JSON_STORE_LOCATION flag.

> > > Error reporting with libjansson is very rudimentary, there is no way
> > > to tell what precisely in the command that is represented in JSON is
> > > actually causing the error, this coarse grain error reporting is too
> > > broad.
> > 
> > Indeed, and my implementation would integrate nicely with nftables'
> > erecs.
> 
> Yes, I like that.
> 
> > I actually considered forking the project. Or we just ship a copy of the
> > lib with nftables sources?
> 
> I would try to get back to them to refresh and retry.

Oh well. I'll try an approach which eliminates the pointer if not
enabled. The terse feedback and pessimistic replies right from the start
convinced me though they just don't want it.

Cheers, Phil

  reply	other threads:[~2023-09-27 13:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 16:02 [PATCH nft 3/3,v2] netlink_linearize: skip set element expression in map statement key Pablo Neira Ayuso
2023-09-26 16:55 ` Phil Sutter
2023-09-27  8:42   ` Pablo Neira Ayuso
2023-09-27 11:10     ` Phil Sutter
2023-09-27 11:19       ` Pablo Neira Ayuso
2023-09-27 13:09         ` Phil Sutter [this message]
2023-09-27 14:41           ` Phil Sutter
2023-09-27 16:52             ` Pablo Neira Ayuso
2023-09-28 14:26               ` 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=ZRQpodNr/9aiVI7H@orbyte.nwl.cc \
    --to=phil@nwl.cc \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).