netdev - Re: [patch iproute2-next v2 3/5] devlink: introduce support for netns id for nested handle

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]

Message-ID: <ZR5kKxNKkLrOoQ4S@nanopsycho>
Date: Thu, 5 Oct 2023 09:22:19 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: David Ahern <dsahern@...il.com>
Cc: netdev@...r.kernel.org, stephen@...workplumber.org,
	daniel.machon@...rochip.com
Subject: Re: [patch iproute2-next v2 3/5] devlink: introduce support for
 netns id for nested handle

Wed, Oct 04, 2023 at 05:20:46PM CEST, dsahern@...il.com wrote:
>On 10/3/23 11:17 AM, Jiri Pirko wrote:
>> Tue, Oct 03, 2023 at 06:37:31PM CEST, dsahern@...il.com wrote:
>>> On 9/29/23 5:30 AM, Jiri Pirko wrote:
>>>>>> The attribute is a namespace id, and the value is a namespace id. Given
>>>>>> that, the name here should be netnsid (or nsid - we did a horrible job
>>>>>> with consistency across iproute2 commands). I have not followed the
>>>>>> kernel patches to understand what you mean by nested devlink instance.
>>>>>
>>>>> Please do that. Again, the netnsid is related to the nested instance.
>>>>> Therefore I put the "nested_devlink" in the name. Putting just "netnsid"
>>>>> as you suggest is wrong. Another possibility would be do nest this into
>>>>> object, but:
>>>>> 1) I didn't find nice way to do that
>>>>> 2) We would break linecards as they expose nested_devlink already
>>>
>>> well, that just shows I make mistakes as a reviewer. These really long
>>> command lines are really taxing.
>> 
>> So what do you suggest?
>
>That you learn how to make up shorter names, leveraging established
>abbreviations for example. This one new parameter is 22 chars. How do
>you expect these command lines and responses to fit on a reasonable
>width terminal? I have been saying this now for many years about devlink
>commands - excessively long attribute names combined with duplicate
>terms in a command line. Not user friendly.

The problem is not the length, the problem is how to group nested
devlink handle and netnsid. Anyway..