On Mon, 12 Aug 2019 08:13:39 -0700, Roopa Prabhu wrote: > On Mon, Aug 12, 2019 at 1:31 AM Jiri Pirko <j...@resnulli.us> wrote: > > Mon, Aug 12, 2019 at 03:37:26AM CEST, dsah...@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! > > Will the below work ?... just throwing an example for discussion: > > make the name list a nested list > IFLA_ALT_NAMES > IFLA_ALT_NAME_OP /* ADD or DEL used with setlink */ > IFLA_ALT_NAME > IFLA_ALT_NAME_LIST > > With RTM_NEWLINK you can specify a list to set and unset > With RTM_SETLINK you can specify an individual name with a add or del op > > notifications will always be RTM_NEWLINK with the full list. > > The nested attribute can be structured differently. > > Only thing is i am worried about increasing the size of link dump and > notification msgs.
Is not adding commands better because it's easier to deal with the RTM_NEWLINK notification? I must say it's unclear from the thread why muxing the op through RTM_SETLINK is preferable. IMHO new op is cleaner, do we have precedent for such IFLA_.*_OP-style attributes?
