On 8/26/19 10:55 PM, Michal Kubecek wrote:

On Mon, Aug 26, 2019 at 03:46:43PM -0600, David Ahern wrote:

quoted

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

quoted

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?

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.

RTM_*ADDR manage network layer addresses. Those are anchored to a device
but not direct attributes describing the device.

The device names are just alternative (human friendly) references to a
specific device hence they should be direct link attributes.