From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Michal Kubecek <mkubecek-AlSwsSmVLrQ@public.gmane.org>
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] netlink: add ethernet address policy types
Date: Thu, 13 Sep 2018 14:46:17 +0200 [thread overview]
Message-ID: <1536842777.4160.9.camel@sipsolutions.net> (raw)
In-Reply-To: <20180913122412.GI29691-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
On Thu, 2018-09-13 at 14:24 +0200, Michal Kubecek wrote:
> On Thu, Sep 13, 2018 at 02:16:06PM +0200, Johannes Berg wrote:
> > On Thu, 2018-09-13 at 14:12 +0200, Michal Kubecek wrote:
> > > On Thu, Sep 13, 2018 at 02:02:53PM +0200, Johannes Berg wrote:
> > > > On Thu, 2018-09-13 at 13:58 +0200, Michal Kubecek wrote:
> > > >
> > > > > The code looks correct to me but I have some doubts. Having a special
> > > > > policy for MAC addresses may lead to adding one for IPv4 address (maybe
> > > > > not, we can use NLA_U32 for them), IPv6 addresses and other data types
> > > > > with fixed length. Wouldn't it be more helpful to add a variant of
> > > > > NLA_BINARY (NLA_BINARY_EXACT?) which would fail/warn if attribute length
> > > > > isn't equal to .len?
> > > >
> > > > Yeah, I guess we could do that, and then
> > > >
> > > > #define NLA_ETH_ADDR .len = ETH_ALEN, .type = NLA_BINARY_EXACT
> > > > #define NLA_IP6_ADDR .len = 16, .type = NLA_BINARY_EXACT
> > > >
> > > > or so?
> > >
> > > Maybe rather
> > >
> > > #define NLA_ETH_ADDR NLA_BINARY_EXACT, .len = ETH_ALEN
> > > #define NLA_IP6_ADDR NLA_BINARY_EXACT, .len = sizeof(struct in6_addr)
> > >
> > > so that one could write
> > >
> > > { .type = NLA_ETH_ADDR }
> >
> > Yeah, that's possible. I considered it for a second, but it was slightly
> > too magical for my taste :-)
> >
> > Better pick a different "namespace", perhaps NLA_POLICY_ETH_ADDR or so?
>
> Right, that sounds better. I'm afraid anything too tricky would
> inevitably trick people into using it in an unexpected way and ending up
> with very confusing error messages.
Right.
Then again though, we already have NLA_MSECS which is basically
equivalent to NLA_U64 afaict, so why not have more types?
It doesn't really cost us that much, just a few bytes in the validation?
Also, with .type = NLA_ETH_ADDR_COMPAT we could get a warning, which is
not true for just checking .len.
OTOH, you could argue that adding two types for ethernet addresses, two
for IPv6 addresses, and possibly more quickly adds up to make that "just
a few bytes" matter ...
johannes
next prev parent reply other threads:[~2018-09-13 12:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 8:46 [PATCH 1/2] netlink: add NLA_REJECT policy type Johannes Berg
2018-09-13 8:46 ` [PATCH 2/2] netlink: add ethernet address policy types Johannes Berg
[not found] ` <20180913084603.7979-2-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-09-13 11:58 ` Michal Kubecek
2018-09-13 12:02 ` Johannes Berg
2018-09-13 12:12 ` Michal Kubecek
2018-09-13 12:16 ` Johannes Berg
[not found] ` <1536840966.4160.6.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-09-13 12:24 ` Michal Kubecek
[not found] ` <20180913122412.GI29691-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
2018-09-13 12:46 ` Johannes Berg [this message]
2018-09-13 16:03 ` Michal Kubecek
2018-09-13 19:41 ` Marcelo Ricardo Leitner
2018-09-13 20:39 ` Michal Kubecek
2018-09-17 7:45 ` Johannes Berg
2018-09-13 10:49 ` [PATCH 1/2] netlink: add NLA_REJECT policy type Michal Kubecek
[not found] ` <20180913104955.GE29691-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
2018-09-13 11:25 ` Johannes Berg
2018-09-13 12:05 ` Michal Kubecek
2018-09-13 19:20 ` Marcelo Ricardo Leitner
2018-09-13 20:43 ` Michal Kubecek
2018-09-13 19:30 ` Marcelo Ricardo Leitner
2018-09-13 21:27 ` Michal Kubecek
2018-09-13 21:58 ` Marcelo Ricardo Leitner
[not found] ` <20180913215839.GI27095-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2018-09-17 9:38 ` Johannes Berg
2018-09-17 20:17 ` Marcelo Ricardo Leitner
[not found] ` <1537177132.2957.6.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2018-09-18 12:34 ` Jamal Hadi Salim
2018-09-18 12:39 ` Johannes Berg
2018-09-18 12:55 ` Jamal Hadi Salim
2018-09-18 12:57 ` Johannes Berg
2018-09-18 13:12 ` Jamal Hadi Salim
2018-09-18 16:42 ` Johannes Berg
2018-09-13 22:59 ` David Miller
[not found] ` <20180913.155934.742447935316828936.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2018-09-17 9:39 ` 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=1536842777.4160.9.camel@sipsolutions.net \
--to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mkubecek-AlSwsSmVLrQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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).