From: Jiri Pirko <jiri@resnulli.us>
To: David Ahern <dsahern@gmail.com>
Cc: Roopa Prabhu <roopa@cumulusnetworks.com>,
netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
dcbw@redhat.com, Michal Kubecek <mkubecek@suse.cz>,
Andrew Lunn <andrew@lunn.ch>,
parav@mellanox.com, Saeed Mahameed <saeedm@mellanox.com>,
mlxsw <mlxsw@mellanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames
Date: Mon, 26 Aug 2019 18:09:16 +0200 [thread overview]
Message-ID: <20190826160916.GE2309@nanopsycho.orion> (raw)
In-Reply-To: <20190813065617.GK2428@nanopsycho>
Tue, Aug 13, 2019 at 08:56:17AM CEST, jiri@resnulli.us wrote:
>Mon, Aug 12, 2019 at 06:01:59PM CEST, dsahern@gmail.com wrote:
>>On 8/12/19 2:31 AM, Jiri Pirko wrote:
>>> Mon, Aug 12, 2019 at 03:37:26AM CEST, dsahern@gmail.com wrote:
>>>> On 8/11/19 7:34 PM, David Ahern wrote:
>>>>> On 8/10/19 12:30 AM, Jiri Pirko wrote:
>>>>>> Could you please write me an example message of add/remove?
>>>>>
>>>>> altnames are for existing netdevs, yes? existing netdevs have an id and
>>>>> a name - 2 existing references for identifying the existing netdev for
>>>>> which an altname will be added. Even using the altname as the main
>>>>> 'handle' for a setlink change, I see no reason why the GETLINK api can
>>>>> not take an the IFLA_ALT_IFNAME and return the full details of the
>>>>> device if the altname is unique.
>>>>>
>>>>> So, what do the new RTM commands give you that you can not do with
>>>>> RTM_*LINK?
>>>>>
>>>>
>>>>
>>>> To put this another way, the ALT_NAME is an attribute of an object - a
>>>> LINK. It is *not* a separate object which requires its own set of
>>>> commands for manipulating.
>>>
>>> Okay, again, could you provide example of a message to add/remove
>>> altname using existing setlink message? Thanks!
>>>
>>
>>Examples from your cover letter with updates
>>
>>$ ip link set dummy0 altname someothername
>>$ ip link set dummy0 altname someotherveryveryveryverylongname
>>
>>$ ip link set dummy0 del altname someothername
>>$ ip link set dummy0 del altname someotherveryveryveryverylongname
>>
>>This syntactic sugar to what is really happening:
>>
>>RTM_NEWLINK, dummy0, IFLA_ALT_IFNAME
>>
>>if you are allowing many alt names, then yes, you need a flag to say
>>delete this specific one which is covered by Roopa's nested suggestion.
>
>Yeah, so you need and op inside the message. We are on the same page,
>thanks.
DaveA, Roopa. Do you insist on doing add/remove of altnames in the
existing setlist command using embedded message op attrs? I'm asking
because after some time thinking about it, it still feels wrong to me :/
If this would be a generic netlink api, we would just add another couple
of commands. What is so different we can't add commands here?
It is also much simpler code. Easy error handling, no need for
rollback, no possibly inconsistent state, etc.
next prev parent reply other threads:[~2019-08-26 16:09 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 11:00 [patch net-next rfc 0/7] net: introduce alternative names for network interfaces Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 1/7] net: procfs: use index hashlist instead of name hashlist Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 2/7] net: introduce name_node struct to be used in hashlist Jiri Pirko
2019-07-19 16:29 ` Stephen Hemminger
2019-07-19 19:17 ` Jiri Pirko
2019-07-19 20:26 ` Stephen Hemminger
2019-07-20 7:15 ` Jiri Pirko
2019-09-13 9:52 ` Jiri Pirko
2019-08-08 4:34 ` kbuild test robot
2019-07-19 11:00 ` [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames Jiri Pirko
2019-07-20 3:58 ` Jakub Kicinski
2019-07-20 7:20 ` Jiri Pirko
2019-08-09 4:11 ` Roopa Prabhu
2019-08-09 6:25 ` Jiri Pirko
2019-08-09 15:40 ` Roopa Prabhu
2019-08-09 15:46 ` Michal Kubecek
2019-08-10 13:46 ` Roopa Prabhu
2019-08-10 15:50 ` Michal Kubecek
2019-08-10 19:39 ` Roopa Prabhu
2019-08-11 22:10 ` Michal Kubecek
2019-08-12 15:21 ` Roopa Prabhu
2019-08-12 15:43 ` Michal Kubecek
2019-08-09 16:14 ` David Ahern
2019-08-10 6:30 ` Jiri Pirko
2019-08-12 1:34 ` David Ahern
2019-08-12 1:37 ` David Ahern
2019-08-12 8:31 ` Jiri Pirko
2019-08-12 15:13 ` Roopa Prabhu
2019-08-12 21:43 ` Jakub Kicinski
2019-08-13 0:29 ` David Ahern
2019-08-13 6:53 ` Jiri Pirko
2019-08-13 6:51 ` Jiri Pirko
2019-08-12 15:40 ` Stephen Hemminger
2019-08-12 16:23 ` Roopa Prabhu
2019-08-13 6:55 ` Jiri Pirko
2019-08-12 16:01 ` David Ahern
2019-08-13 6:56 ` Jiri Pirko
2019-08-26 16:09 ` Jiri Pirko [this message]
2019-08-26 16:55 ` Jakub Kicinski
2019-08-26 21:46 ` David Ahern
2019-08-26 22:15 ` Jakub Kicinski
2019-08-26 22:18 ` David Miller
2019-08-26 22:24 ` David Ahern
2019-08-26 22:25 ` David Miller
2019-08-27 0:17 ` David Ahern
2019-08-27 5:09 ` Michal Kubecek
2019-08-27 7:08 ` Jiri Pirko
2019-08-27 8:22 ` David Miller
2019-08-27 9:35 ` Jiri Pirko
2019-08-27 15:14 ` Roopa Prabhu
2019-08-28 7:07 ` Jiri Pirko
2019-08-29 4:36 ` Roopa Prabhu
2019-08-29 5:26 ` Michal Kubecek
2019-08-30 14:35 ` Roopa Prabhu
2019-08-30 14:47 ` David Ahern
2019-08-30 17:04 ` Jiri Pirko
2019-08-30 14:49 ` Michal Kubecek
2019-08-30 17:03 ` Jiri Pirko
2019-09-12 11:59 ` Jiri Pirko
2019-09-13 8:21 ` Jiri Pirko
2019-09-13 14:50 ` Jiri Pirko
2019-08-27 4:55 ` Michal Kubecek
2019-08-27 13:43 ` David Ahern
2019-08-10 6:32 ` Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 4/7] net: rtnetlink: put alternative names to getlink message Jiri Pirko
2019-07-20 3:59 ` Jakub Kicinski
2019-07-20 7:17 ` Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 5/7] net: rtnetlink: unify the code in __rtnl_newlink get dev with the rest Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 6/7] net: rtnetlink: introduce helper to get net_device instance by ifname Jiri Pirko
2019-07-19 11:00 ` [patch net-next rfc 7/7] net: rtnetlink: add possibility to use alternative names as message handle Jiri Pirko
2019-07-20 3:59 ` Jakub Kicinski
2019-07-20 7:22 ` Jiri Pirko
2019-07-19 11:03 ` [patch iproute2 rfc 1/2] ip: add support for alternative name addition/deletion/list Jiri Pirko
2019-07-19 11:03 ` [patch iproute2 rfc 2/2] ip: allow to use alternative names as handle Jiri Pirko
2019-07-19 16:31 ` [patch net-next rfc 0/7] net: introduce alternative names for network interfaces Stephen Hemminger
2019-07-19 19:16 ` Jiri Pirko
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=20190826160916.GE2309@nanopsycho.orion \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=dsahern@gmail.com \
--cc=jakub.kicinski@netronome.com \
--cc=mkubecek@suse.cz \
--cc=mlxsw@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=parav@mellanox.com \
--cc=roopa@cumulusnetworks.com \
--cc=saeedm@mellanox.com \
--cc=sthemmin@microsoft.com \
/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).