[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221017114408.1c1bd0a7@kernel.org>
Date: Mon, 17 Oct 2022 11:44:08 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: Jiri Pirko <jiri@...nulli.us>, ecree@...inx.com,
netdev@...r.kernel.org, linux-net-drivers@....com,
davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
habetsm.xilinx@...il.com, johannes@...solutions.net,
marcelo.leitner@...il.com
Subject: Re: [RFC PATCH net-next 1/3] netlink: add support for formatted
extack messages
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
Powered by blists - more mailing lists