[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170425135306.0ff1db27@cakuba.netronome.com>
Date: Tue, 25 Apr 2017 13:53:06 -0700
From: Jakub Kicinski <kubakici@...pl>
To: Johannes Berg <johannes@...solutions.net>, daniel@...earbox.net
Cc: netdev@...r.kernel.org, davem@...emloft.net,
dsa@...ulusnetworks.com, alexei.starovoitov@...il.com,
bblanco@...il.com, john.fastabend@...il.com, kubakici@...pl,
oss-drivers@...ronome.com
Subject: Re: [RFC 1/4] netlink: make extended ACK setting NULL-friendly
On Tue, 25 Apr 2017 10:13:34 +0200, Johannes Berg wrote:
> On Tue, 2017-04-25 at 01:06 -0700, Jakub Kicinski wrote:
>
> > +#define NL_SET_ERR_MSG(extack, msg) do { \
> > + struct netlink_ext_ack *_extack = (extack); \
> > + static const char _msg[] = (msg); \
> > + \
> > + if (_extack) \
> > + _extack->_msg = _msg; \
> > + else \
> > + pr_info("%s\n", _msg); \
> > } while (0)
>
> That's a good point, I used it only for genetlink so far where it was
> guaranteed non-NULL.
>
> I'm not really sure about the printing though - I'd rather not people
> start relying on that and then we convert to have non-NULL and the
> message disappears as a result ...
Yes, agreed. I don't really know what to do about that one though :|
One could argue people may already be depending on the messages which
I'm converting in this series... On the other hand, that would
be considering logs as part of the ABI which we don't want to do.
I'm leaning towards dropping the else clause and never printing, that
will add an incentive for people to convert more paths to provide the
ext ack. Any thoughts on that?
Powered by blists - more mailing lists