On 8/9/19 9:40 AM, Roopa Prabhu wrote: >>>> 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.