[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250418170803.5afa2ddf@kernel.org>
Date: Fri, 18 Apr 2025 17:08:03 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
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 V2 01/14] devlink: define enum for attr types
of dynamic attributes
On Fri, 18 Apr 2025 12:26:50 +0200 Jiri Pirko wrote:
> Thu, Apr 17, 2025 at 03:08:26AM +0200, kuba@...nel.org wrote:
> >On Mon, 14 Apr 2025 12:59:46 -0700 Saeed Mahameed wrote:
> >> From: Jiri Pirko <jiri@...dia.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 ?
Powered by blists - more mailing lists