netdev - Re: [PATCH net-next V3 02/15] devlink: define enum for attr types of dynamic attributes

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: <fy5y73vfqfajxnm6hkzd5h4rw4xohz6tormbi6mgnnerptomlv@jwsxzuqdn7io>
Date: Tue, 29 Apr 2025 13:49:16 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Saeed Mahameed <saeed@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, 
	Eric Dumazet <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org, 
	Tariq Toukan <tariqt@...dia.com>, Gal Pressman <gal@...dia.com>, 
	Leon Romanovsky <leonro@...dia.com>, Jiri Pirko <jiri@...dia.com>
Subject: Re: [PATCH net-next V3 02/15] devlink: define enum for attr types of
 dynamic attributes

Tue, Apr 29, 2025 at 09:20:40AM +0200, jiri@...nulli.us wrote:
>Tue, Apr 29, 2025 at 01:10:31AM +0200, kuba@...nel.org wrote:
>>On Fri, 25 Apr 2025 14:47:55 -0700 Saeed Mahameed wrote:
>>> +/**
>>> + * enum devlink_var_attr_type - Dynamic attribute type type.
>>
>>we no longer have "dynamic" in the name
>>
>>> + */
>>> +enum devlink_var_attr_type {
>>> +	/* Following values relate to the internal NLA_* values */
>>> +	DEVLINK_VAR_ATTR_TYPE_U8 = 1,
>>> +	DEVLINK_VAR_ATTR_TYPE_U16,
>>> +	DEVLINK_VAR_ATTR_TYPE_U32,
>>> +	DEVLINK_VAR_ATTR_TYPE_U64,
>>> +	DEVLINK_VAR_ATTR_TYPE_STRING,
>>> +	DEVLINK_VAR_ATTR_TYPE_FLAG,
>>> +	DEVLINK_VAR_ATTR_TYPE_NUL_STRING = 10,
>>> +	DEVLINK_VAR_ATTR_TYPE_BINARY,
>>> +	__DEVLINK_VAR_ATTR_TYPE_CUSTOM_BASE = 0x80,
>>> +	/* Any possible custom types, unrelated to NLA_* values go below */
>>> +};
>>> +
>>>  enum devlink_attr {
>>>  	/* don't change the order or add anything between, this is ABI! */
>>>  	DEVLINK_ATTR_UNSPEC,
>>
>>>  static int
>>> -devlink_param_type_to_nla_type(enum devlink_param_type param_type)
>>> +devlink_param_type_to_var_attr_type(enum devlink_param_type param_type)
>>>  {
>>>  	switch (param_type) {
>>>  	case DEVLINK_PARAM_TYPE_U8:
>>> -		return NLA_U8;
>>> +		return DEVLINK_VAR_ATTR_TYPE_U8;
>>>  	case DEVLINK_PARAM_TYPE_U16:
>>> -		return NLA_U16;
>>> +		return DEVLINK_VAR_ATTR_TYPE_U16;
>>>  	case DEVLINK_PARAM_TYPE_U32:
>>> -		return NLA_U32;
>>> +		return DEVLINK_VAR_ATTR_TYPE_U32;
>>>  	case DEVLINK_PARAM_TYPE_STRING:
>>> -		return NLA_STRING;
>>> +		return DEVLINK_VAR_ATTR_TYPE_STRING;
>>>  	case DEVLINK_PARAM_TYPE_BOOL:
>>> -		return NLA_FLAG;
>>> +		return DEVLINK_VAR_ATTR_TYPE_FLAG;
>>>  	default:
>>>  		return -EINVAL;
>>
>>Why do you keep the DEVLINK_PARAM_TYPE_* defines around?
>>IMO it'd be fine to just use them directly instead of adding 
>>the new enum, fmsg notwithstanding. But failing that we can rename 
>>in the existing in-tree users to DEVLINK_VAR_ATTR_TYPE_* right?
>>What does this translating back and forth buy us?
>
>Sure, I can do that in a separate patch. I think I will send these
>patchset separatelly prior to Saeed's patchset.

Hmm, on a second thought, we expose DEVLINK_PARAM_TYPE_* to drivers to
specify type of driver-specific params:
git grep DEVLINK_PARAM_TYPE_
I would like to keep it as part of devlink param api. Looks nicer to me.
Downside is this switch-case, but who really cares?

Thanks!

>
>>