Messages in this thread | | | Date | Tue, 17 May 2022 16:54:19 -0700 | From | Jakub Kicinski <> | Subject | Re: [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.
| |