lkml.org 
[lkml]   [2022]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC net-next] bonding: netlink error message support for options
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.

\
 
 \ /
  Last update: 2022-05-18 01:55    [W:0.071 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site