Thread (76 messages) 76 messages, 8 authors, 2019-09-13

Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames

From: Jiri Pirko <jiri@resnulli.us>
Date: 2019-08-10 06:30:53

Fri, Aug 09, 2019 at 06:14:03PM CEST, dsahern@gmail.com wrote:
On 8/9/19 9:40 AM, Roopa Prabhu wrote:
quoted
quoted
quoted
quoted
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index ce2a623abb75..b36cfd83eb76 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -164,6 +164,13 @@ enum {
        RTM_GETNEXTHOP,
 #define RTM_GETNEXTHOP RTM_GETNEXTHOP

+       RTM_NEWALTIFNAME = 108,
+#define RTM_NEWALTIFNAME       RTM_NEWALTIFNAME
+       RTM_DELALTIFNAME,
+#define RTM_DELALTIFNAME       RTM_DELALTIFNAME
+       RTM_GETALTIFNAME,
+#define RTM_GETALTIFNAME       RTM_GETALTIFNAME
+
I might have missed the prior discussion, why do we need new commands
?. can't this simply be part of RTM_*LINK and we use RTM_SETLINK to
set alternate names ?
How? This is to add/remove. How do you suggest to to add/remove by
setlink?
to that point, I am also not sure why we have a new API For multiple
names. I mean why support more than two names  (existing old name and
a new name to remove the length limitation) ?

Your patch series addresses a very important problem (we run into this
limitation all  the time and its hard to explain it to network
operators) and
 its already unfortunate that we have to have more than one name
because we cannot resize the existing one.

The best we can do for simpler transition/management from user-space
is to keep the api simple..
ie keep it close to the management of existing link attributes. Hence
the question.

I assumed this would be like alias. A single new field that can be
referenced in lieu of the old one.

Your series is very useful to many of us...but when i think about
changing our network manager to accommodate this, I am worried about
how many apps will have to change.
I agree they have to change regardless but now they will have to
listen to yet another notification and msg format for names ?

(apologies for joining the thread late and if i missed prior discussion on this)
I agree with Roopa. I do not understand why new RTM commands are needed.
The existing IFLA + ifinfomsg struct give more than enough ways to id
the device for adding / deleting an alternate name.
Could you please write me an example message of add/remove?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help