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] [thread-next>] [day] [month] [year] [list]
Message-ID: <53ad4e54-47c7-4afa-a296-635e10192f8c@lunn.ch>
Date: Tue, 28 Oct 2025 14:58:59 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
	pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
	donald.hunter@...il.com, ast@...erby.net
Subject: Re: [PATCH net-next v2 2/2] tools: ynl: rework the string
 representation of NlError

On Mon, Oct 27, 2025 at 12:29:58PM -0700, Jakub Kicinski wrote:
> In early days of YNL development dumping the NlMsg on errors
> was quite useful, as the library itself could have been buggy.
> These days increasingly the NlMsg is just taking up screen space
> and means nothing to a typical user. Try to format the errors
> more in line with how YNL C formats its errors strings.
> 
> Before:
>   $ ynl --family ethtool  --do channels-set  --json '{}'
>   Netlink error: Invalid argument
>   nl_len = 44 (28) nl_flags = 0x300 nl_type = 2
> 	error: -22
> 	extack: {'miss-type': 'header'}
> 
>   $ ynl --family ethtool  --do channels-set  --json '{..., "tx-count": 999}'
>   Netlink error: Invalid argument
>   nl_len = 88 (72) nl_flags = 0x300 nl_type = 2
> 	error: -22
> 	extack: {'msg': 'requested channel count exceeds maximum', 'bad-attr': '.tx-count'}
> 
> After:
>   $ ynl --family ethtool  --do channels-set  --json '{}'
>   Netlink error: Invalid argument {'miss-type': 'header'}
> 
>   $ ynl --family ethtool  --do channels-set  --json '{..., "tx-count": 999}'
>   Netlink error: requested channel count exceeds maximum: Invalid argument {'bad-attr': '.tx-count'}

I think as a kernel programmer, i would prefer EINVAL over Invalid
argument. If i'm going to be digging into the kernel sources to find
where the error is happening, it is one less translation i need to
make.

>>> print(errno.errorcode[1])
EPERM
>>> print(errno.errorcode[2])
ENOENT
>>> print(errno.errorcode[110])
ETIMEDOUT

I suppose the question is, who is the intended user of ynl? Do we want
user friendly messages, or kernel developer friendly messages?

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ