From: Johannes Berg <johannes@sipsolutions.net>
To: David Ahern <dsahern@gmail.com>,
Michal Kubecek <mkubecek@suse.cz>,
netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Jiri Pirko <jiri@mellanox.com>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
Florian Westphal <fw@strlen.de>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/3] make nla_nest_start() add NLA_F_NESTED flag
Date: Fri, 26 Apr 2019 18:02:38 +0200 [thread overview]
Message-ID: <9d9f2e4465ce80593b3a5d08e9948304bdcefbf4.camel@sipsolutions.net> (raw)
In-Reply-To: <47f6daf9-2d14-1566-8ed1-fb5d4dd57bf8@gmail.com> (sfid-20190426_170019_042586_CEF2CE11)
On Fri, 2019-04-26 at 09:00 -0600, David Ahern wrote:
>
> What is a valid use case for an attribute sometimes being a nest and
> sometimes not? That seems really weird to me (ie., wrong). They should
> be 2 separate attributes even if the backend processing is the same.
Yeah, well, in the mentioned case - NL80211_ATTR_VENDOR_DATA - we
basically have something that each driver (sometimes each operation that
uses it) decides what it means, and most drivers like proper netlink
attributes so have nested stuff there. Sometimes not, though in Prague
we decided we should make that documented by requiring a nested policy
and (perhaps, TBD) using something like an ERR_PTR() for "I really want
this to be binary".
I think as far as this particular attribute is concerned the ship has
sailed, but in the future I'd probably advocate having two attributes.
johannes
next prev parent reply other threads:[~2019-04-26 16:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 9:13 [PATCH net-next 0/3] make nla_nest_start() add NLA_F_NESTED flag Michal Kubecek
2019-04-26 9:13 ` [PATCH net-next 1/3] netlink: " Michal Kubecek
2019-04-26 10:51 ` Jiri Pirko
2019-04-26 15:03 ` David Ahern
2019-04-26 9:13 ` [PATCH net-next 2/3] ipset: drop ipset_nest_start() and ipset_nest_end() Michal Kubecek
2019-04-26 16:59 ` Jozsef Kadlecsik
2019-04-26 9:13 ` [PATCH net-next 3/3] net: fix two coding style issues Michal Kubecek
2019-04-26 9:24 ` [PATCH net-next 0/3] make nla_nest_start() add NLA_F_NESTED flag Johannes Berg
2019-04-26 11:19 ` Michal Kubecek
2019-04-26 11:23 ` Johannes Berg
2019-04-26 11:56 ` Michal Kubecek
2019-04-26 12:17 ` Johannes Berg
2019-04-26 15:00 ` David Ahern
2019-04-26 16:02 ` Johannes Berg [this message]
2019-04-26 16:45 ` Michal Kubecek
2019-04-27 21:04 ` David Miller
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=9d9f2e4465ce80593b3a5d08e9948304bdcefbf4.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=fw@strlen.de \
--cc=jiri@mellanox.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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).