On Mon, Aug 26, 2019 at 03:46:43PM -0600, David Ahern wrote: > On 8/26/19 10:55 AM, Jakub Kicinski wrote: > > On Mon, 26 Aug 2019 18:09:16 +0200, Jiri Pirko wrote: > >> 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. > > > > +1 the separate op feels like a better uapi to me as well. > > > > Perhaps we could redo the iproute2 command line interface to make the > > name the primary object? Would that address your concern Dave and Roopa? > > > > No, my point is exactly that a name is not a primary object. A name is > an attribute of a link - something that exists for the convenience of > userspace only. (Like the 'protocol' for routes, rules and neighbors.) > > Currently, names are changed by RTM_NEWLINK/RTM_SETLINK. Aliases are > added and deleted by RTM_NEWLINK/RTM_SETLINK. Why is an alternative name > so special that it should have its own API?
There is only one alias so that it makes perfect sense to set it like any other attribute. But the series introduces a list of alternative names. So IMHO better analogy would be network addresses - and we do have RTM_NEWADDR/RTM_DELADDR for them. > If only 1 alt name was allowed, then RTM_NEWLINK/RTM_SETLINK would > suffice. Management of it would have the same semantics as an alias - > empty string means delete, non-empty string sets the value. > > So really the push for new RTM commands is to handle an unlimited number > of alt names with the ability to change / delete any one of them. Has > the need for multiple alternate ifnames been fully established? (I don't > recall other than a discussion about parallels to block devices.) I still believe the biggest problem with so-called "predictable names" for network devices (which turn out to be not predictable and often not even persistent) comes from the fact that unlike for block (or character) devices, we don't have anything like symlink for network device. This forces udev to choose only one naming scheme with all the unpleasant consequences. So I see this series as an opportunity to get rid of this limitation. Michal
