[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190720072250.GJ2230@nanopsycho>
Date: Sat, 20 Jul 2019 09:22:50 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
sthemmin@...rosoft.com, dsahern@...il.com, dcbw@...hat.com,
mkubecek@...e.cz, andrew@...n.ch, parav@...lanox.com,
saeedm@...lanox.com, mlxsw@...lanox.com
Subject: Re: [patch net-next rfc 7/7] net: rtnetlink: add possibility to use
alternative names as message handle
Sat, Jul 20, 2019 at 05:59:27AM CEST, jakub.kicinski@...ronome.com wrote:
>On Fri, 19 Jul 2019 13:00:29 +0200, Jiri Pirko wrote:
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 1fa30d514e3f..68ad12a7fc4d 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -1793,6 +1793,8 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
>> [IFLA_MAX_MTU] = { .type = NLA_U32 },
>> [IFLA_ALT_IFNAME_MOD] = { .type = NLA_STRING,
>> .len = ALTIFNAMSIZ - 1 },
>> + [IFLA_ALT_IFNAME] = { .type = NLA_STRING,
>> + .len = ALTIFNAMSIZ - 1 },
>
>What's the disadvantage of just letting IFLA_IFNAME to get longer
>on input? Is it just that the handling would be asymmetrical?
Hmm, that might work. But the problem is that sometimes the IFLA_IFNAME
is used as a handle, but sometimes it is used to carry the ifname
(newlink, changename). That might be a bit confusing and the code would
be harder to follow. I don't know...
>
>> };
>>
>> static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>
Powered by blists - more mailing lists