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? 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.)
