netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Edward Cree <ecree.xilinx@gmail.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
	ecree@xilinx.com, netdev@vger.kernel.org,
	linux-net-drivers@amd.com, davem@davemloft.net,
	pabeni@redhat.com, edumazet@google.com, habetsm.xilinx@gmail.com,
	johannes@sipsolutions.net, marcelo.leitner@gmail.com
Subject: Re: [RFC PATCH net-next 1/3] netlink: add support for formatted extack messages
Date: Mon, 17 Oct 2022 11:44:08 -0700	[thread overview]
Message-ID: <20221017114408.1c1bd0a7@kernel.org> (raw)
In-Reply-To: <43513470-fd59-4d18-f66e-0aecfcfc8404@gmail.com>

On Mon, 17 Oct 2022 13:00:55 +0100 Edward Cree wrote:
> > I wonder, wouldn't it be better to just have NL_SET_ERR_MSG_MOD which
> > accepts format string and that's it. I understand there is an extra
> > overhead for the messages that don't use formatting, but do we care?
> > This is no fastpath and usually happens only seldom. The API towards
> > the driver would be more simple.  
> 
> Could do, but this way a fixed string isn't limited to
>  NETLINK_MAX_FMTMSG_LEN like it would be if we tried to stuff it
>  in _msg_buf.  Unless you're suggesting some kind of macro magic
>  that detects whether args is empty and chooses which
>  implementation to use, but that seems like excessive hidden
>  cleverness — better to have driver authors aware of the
>  limitations of each choice.

No macro magic, if we wanna go the extra mile we'd need to run some
analysis. We can choose the limit based on the longest message today.

If spatch could output matches that'd make the analysis pretty trivial
but IDK if it can :S

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

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 13:25 [RFC PATCH net-next 0/3] netlink: formatted extacks ecree
2022-10-07 13:25 ` [RFC PATCH net-next 1/3] netlink: add support for formatted extack messages ecree
2022-10-07 13:35   ` Johannes Berg
2022-10-07 13:46     ` Edward Cree
2022-10-07 13:49       ` Johannes Berg
2022-10-07 13:58         ` Edward Cree
2022-10-13 12:59         ` Jiri Pirko
2022-10-13 13:35           ` Edward Cree
2022-10-07 18:32       ` Jakub Kicinski
2022-10-13 12:55   ` Jiri Pirko
2022-10-17 12:00     ` Edward Cree
2022-10-17 18:44       ` Jakub Kicinski [this message]
2022-10-07 13:25 ` [RFC PATCH net-next 2/3] sfc: use formatted extacks instead of efx_tc_err() ecree
2022-10-07 13:25 ` [RFC PATCH net-next 3/3] sfc: remove 'log-tc-errors' ethtool private flag ecree

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=20221017114408.1c1bd0a7@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=ecree@xilinx.com \
    --cc=edumazet@google.com \
    --cc=habetsm.xilinx@gmail.com \
    --cc=jiri@resnulli.us \
    --cc=johannes@sipsolutions.net \
    --cc=linux-net-drivers@amd.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 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).