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: <20250428161031.2e64b41f@kernel.org>
Date: Mon, 28 Apr 2025 16:10:31 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Saeed Mahameed <saeed@...nel.org>
Cc: "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

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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ