On 8/26/19 10:55 PM, Michal Kubecek wrote: > 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.
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.
