Re: [PATCH net-next V2 01/14] devlink: define enum for attr types of dynamic attributes

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 18 Apr 2025 12:26:50 +0200 Jiri Pirko wrote:
> Thu, Apr 17, 2025 at 03:08:26AM +0200, kuba@kernel.org wrote:
> >On Mon, 14 Apr 2025 12:59:46 -0700 Saeed Mahameed wrote:  
> >> From: Jiri Pirko <jiri@nvidia.com>
> >> 
> >> Devlink param and health reporter fmsg use attributes with dynamic type
> >> which is determined according to a different type. Currently used values
> >> are NLA_*. The problem is, they are not part of UAPI. They may change
> >> which would cause a break.
> >> 
> >> To make this future safe, introduce a enum that shadows NLA_* values in
> >> it and is part of UAPI.
> >> 
> >> Also, this allows to possibly carry types that are unrelated to NLA_*
> >> values.  
> >
> >I don't think you need to expose this in C. I had to solve this
> >problem for rtnl because we nested dpll attrs in link info. Please see:
> >
> >https://github.com/kuba-moo/linux/commit/6faf7a638d0a5ded688a22a1337f56470dca85a3
> >
> >and look at the change for dpll here (sorry IDK how to link to a line :S)
> >
> >https://github.com/kuba-moo/linux/commit/00c8764ebb12f925b6f1daedd5e08e6fac478bfd
> >
> >With that you can add the decode info to the YAML spec for Python et al.
> >but there's no need do duplicate the values. Right now this patch
> >generates a bunch of "missing kdoc" warnings.
> >
> >Ima start sending those changes after the net -> net-next merge,
> >some of the prep had to go to net :(  
> 
> I may be missing something, I don't see how your work is related to
> mine. The problem I'm trying to solve is that kernel sends NLA_* values
> to userspace, without NLA_* being part of UAPI. At any time (even unlikely),
> NLA_* values in kernel may change and that would break the userspace
> suddenly getting different values.
> 
> Therefore, I introduce an enum for this. This is how it should have been
> done from day 1, it's a bug in certain sense. Possibility to carry
> non-NLA_* type in this enum is a plus we benefit from later in this
> patchset.

Ugh, I thought enum netlink_attribute_type matches the values :|
And user space uses MNL_ types.

Please don't invent _DYN_ATTR at least. Why not PARAM_TYPE ?