From: Jakub Kicinski <kuba@kernel.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Jonathan Toppins <jtoppins@redhat.com>,
netdev@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com>,
Veaceslav Falico <vfalico@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC net-next] bonding: netlink error message support for options
Date: Tue, 17 May 2022 16:54:19 -0700 [thread overview]
Message-ID: <20220517165419.540f2dc8@kernel.org> (raw)
In-Reply-To: <20220517154419.44a1cb6a@hermes.local>
On Tue, 17 May 2022 15:44:19 -0700 Stephen Hemminger wrote:
> On Tue, 17 May 2022 16:31:19 -0400
> Jonathan Toppins <jtoppins@redhat.com> wrote:
>
> > This is an RFC because the current NL_SET_ERR_MSG() macros do not support
> > printf like semantics so I rolled my own buffer setting in __bond_opt_set().
> > The issue is I could not quite figure out the life-cycle of the buffer, if
> > rtnl lock is held until after the text buffer is copied into the packet
> > then we are ok, otherwise, some other type of buffer management scheme will
> > be needed as this could result in corrupted error messages when modifying
> > multiple bonds.
>
> Might be better for others in long term if NL_SET_ERR_MSG() had printf like
> semantics. Surely this isn't going to be first or last case.
>
> Then internally, it could print right to the netlink message.
Dunno. I think pointing at the bad attr + exposing per-attr netlink
parsing policy + a string for a human worked pretty well so far.
IMHO printf() is just a knee jerk reaction, especially when converting
from netdev_err().
Augmenting structured information is much, much better long term.
To me the never ending stream of efforts to improve printk() is a
proof that once we let people printf() at will, efforts to contain
it will be futile.
next prev parent reply other threads:[~2022-05-17 23:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 20:31 [RFC net-next] bonding: netlink error message support for options Jonathan Toppins
2022-05-17 21:11 ` Jay Vosburgh
2022-05-17 22:33 ` Jakub Kicinski
2022-05-17 22:44 ` Stephen Hemminger
2022-05-17 23:54 ` Jakub Kicinski [this message]
2022-05-18 3:37 ` Jonathan Toppins
2022-05-27 19:59 ` [RFC net-next v2] " Jonathan Toppins
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=20220517165419.540f2dc8@kernel.org \
--to=kuba@kernel.org \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=j.vosburgh@gmail.com \
--cc=jtoppins@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stephen@networkplumber.org \
--cc=vfalico@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.