netdev - Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and delete alternative ifnames

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 13 Sep 2019 16:50:12 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     Michal Kubecek <mkubecek@...e.cz>, netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        David Ahern <dsahern@...il.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>, dcbw@...hat.com,
        Andrew Lunn <andrew@...n.ch>, parav@...lanox.com,
        Saeed Mahameed <saeedm@...lanox.com>,
        mlxsw <mlxsw@...lanox.com>
Subject: Re: [patch net-next rfc 3/7] net: rtnetlink: add commands to add and
 delete alternative ifnames

Thu, Sep 12, 2019 at 01:59:42PM CEST, jiri@...nulli.us wrote:
>Fri, Aug 30, 2019 at 07:03:42PM CEST, jiri@...nulli.us wrote:
>>Fri, Aug 30, 2019 at 04:35:23PM CEST, roopa@...ulusnetworks.com wrote:
>
>[...]
>
>>>
>>>so to summarize, i think we have discussed the following options to
>>>update a netlink list attribute so far:
>>>(a) encode an optional attribute/flag in the list attribute in
>>>RTM_SETLINK to indicate if it is a add or del
>>>(b) Use a flag in RTM_SETLINK and RTM_DELINK to indicate add/del
>>>(close to bridge vlan add/del)
>>
>>Nope, bridge vlan add/del is done according to the cmd, not any flag.
>>
>>
>>>(c) introduce a separate generic msg type to add/del to a list
>>>attribute (IIUC this does need a separate msg type per subsystem or
>>>netlink API)
>
>Getting back to this, sorry.
>
>Thinking about it for some time, a,b,c have all their issues. Why can't
>we have another separate cmd as I originally proposed in this RFC? Does
>anyone have any argument against it? Could you please describe?
>
>Because otherwise, I don't feel comfortable going to any of a,b,c :(

How about this:

We have new commands, but we have them for lists of many types. In my
examples, I'm using "altname" and "color". This is very similar to
bridge vlan example Roopa pointed out. It scales and does not pollute
existing setlink/getlink messages. Also, the cmdline is aligned:


$ ip link property add eth0 altname someverylongname altname someotherlongname

$ ip link property add eth0 altname someotherveryverylongname color blue

$ ip link property del eth0 altname someverylongname color blue

$ ip link property add eth0 color red

$ ip link property show eth0
2: eth0: altname someotherlongname altname someotherveryverylongname color red

$ ip -j -p link property show eth0
[ {
        "ifindex": 2,
        "ifname": "eth0",
        "property": [ "altname": "someotherlongname",
	              "altname": "someotherveryverylongname",
	              "color": "red"]
    } ]

I call this "property" but I'm open to any other naming.