On Tue, Aug 27, 2019 at 2:35 AM Jiri Pirko <j...@resnulli.us> wrote: > > Tue, Aug 27, 2019 at 10:22:42AM CEST, da...@davemloft.net wrote: > >From: Jiri Pirko <j...@resnulli.us> > >Date: Tue, 27 Aug 2019 09:08:08 +0200 > > > >> Okay, so if I understand correctly, on top of separate commands for > >> add/del of alternative names, you suggest also get/dump to be separate > >> command and don't fill this up in existing newling/getlink command. > > > >I'm not sure what to do yet. > > > >David has a point, because the only way these ifnames are useful is > >as ways to specify and choose net devices. So based upon that I'm > >slightly learning towards not using separate commands. > > Well yeah, one can use it to handle existing commands instead of > IFLA_NAME. > > But why does it rule out separate commands? I think it is cleaner than > to put everything in poor setlink messages :/ The fact that we would > need to add "OP" to the setlink message just feels of. Other similar > needs may show up in the future and we may endup in ridiculous messages > like: > > SETLINK > IFLA_NAME eth0 > IFLA_ATLNAME_LIST (nest) > IFLA_ALTNAME_OP add > IFLA_ALTNAME somereallylongname > IFLA_ALTNAME_OP del > IFLA_ALTNAME somereallyreallylongname > IFLA_ALTNAME_OP add > IFLA_ALTNAME someotherreallylongname > IFLA_SOMETHING_ELSE_LIST (nest) > IFLA_SOMETHING_ELSE_OP add > ... > IFLA_SOMETHING_ELSE_OP del > ... > IFLA_SOMETHING_ELSE_OP add > ... > > I don't know what to think about it. Rollbacks are going to be pure hell :/
I don't see a huge problem with the above. We need a way to solve this anyways for other list types in the future correct ?. The approach taken by this series will not scale if we have to add a new msg type and header for every such list attribute in the future. A good parallel here is bridge vlan which uses RTM_SETLINK and RTM_DELLINK for vlan add and deletes. But it does have an advantage of a separate msg space under AF_BRIDGE which makes it cleaner. Maybe something closer to that can be made to work (possibly with a msg flag) ?. Would be good to have a consistent way to update list attributes for future needs too.
