From: Pablo Neira Ayuso <pablo@netfilter.org>
To: David Miller <davem@davemloft.net>
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, jiri@resnulli.us
Subject: Re: [RFC 0/3] netlink: extended error reporting
Date: Fri, 7 Apr 2017 21:35:50 +0200 [thread overview]
Message-ID: <20170407193550.GA23424@salvia> (raw)
In-Reply-To: <20170407.122053.201153373954521345.davem@davemloft.net>
On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote:
[...]
> Let's just discuss the UAPI, since people complain we don't talk
> about that enough :-) For those playing at home it is three new
> attributes returned in a netlink ACK when the application asks
> for the extended response:
>
> NLMSGERR_ATTR_MSG string Extended error string
> NLMSGERR_ATTR_OFFS u32 Byte offset to netlink element causing error
> NLMSGERR_ATTR_CODE u32 Subsystem specific error code
> NLMSGERR_ATTR_ATTR u16 Netlink attribute triggering error or missing
I think it would be good if we get a definition to cap the maximum
string length to something reasonable? This can be added in a follow
up patch BTW. Thus, we get people coming back to us and request larger
strings with a reason why they need more room for this.
In general, my main concern with strings is that they can be used in a
more freely way than these u32 offsets and error codes, and
specifically how inconsistent these string will look like across
different netlink subsystems.
Anyway, as long as this is optional (not every subsystem if forced to
use strings) I'm fine with it :).
next prev parent reply other threads:[~2017-04-07 19:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 18:26 [RFC 0/3] netlink: extended error reporting Johannes Berg
2017-04-07 18:26 ` [RFC 1/3] " Johannes Berg
2017-04-07 19:41 ` Johannes Berg
2017-04-07 18:26 ` [RFC 2/3] genetlink: pass extended error report down Johannes Berg
2017-04-07 18:37 ` Ben Greear
[not found] ` <25e1fb8c-22e0-d7a2-13a7-d0def5432c9e-my8/4N5VtI7c+919tysfdA@public.gmane.org>
2017-04-07 19:12 ` Johannes Berg
2017-04-07 19:27 ` Ben Greear
[not found] ` <20170407182620.6438-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 18:26 ` [RFC 3/3] nl80211: add a few extended error strings Johannes Berg
2017-04-07 18:53 ` [RFC 0/3] netlink: extended error reporting David Miller
[not found] ` <20170407.115315.23470877439489670.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 18:59 ` Johannes Berg
[not found] ` <1491591552.5800.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 19:06 ` Pablo Neira Ayuso
2017-04-07 19:09 ` Johannes Berg
2017-04-07 19:21 ` Pablo Neira Ayuso
2017-04-07 19:29 ` Johannes Berg
[not found] ` <1491593357.5800.13.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 19:45 ` Pablo Neira Ayuso
2017-04-07 19:47 ` Johannes Berg
2017-04-07 19:34 ` David Miller
2017-04-07 19:22 ` David Miller
[not found] ` <20170407.122223.385211483743191711.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 19:27 ` Pablo Neira Ayuso
2017-04-07 19:29 ` Johannes Berg
2017-04-07 19:34 ` David Miller
2017-04-07 19:20 ` David Miller
2017-04-07 19:26 ` Johannes Berg
2017-04-07 19:35 ` Pablo Neira Ayuso [this message]
2017-04-07 19:43 ` David Miller
[not found] ` <20170407.124327.626442219286333933.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 19:46 ` Johannes Berg
[not found] ` <1491594406.5800.18.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-07 19:55 ` David Miller
[not found] ` <20170407.125511.1233528940652477012.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-07 20:27 ` Johannes Berg
2017-04-07 19:02 ` Pablo Neira Ayuso
2017-04-07 19:06 ` Johannes Berg
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=20170407193550.GA23424@salvia \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).