On 8/26/19 10:55 AM, Jakub Kicinski wrote:

On Mon, 26 Aug 2019 18:09:16 +0200, Jiri Pirko wrote:

quoted

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