Re: [PATCH bpf-next v1 2/3] bpf: allow void* cast using bpf_rdonly_cast()

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2025-06-24 at 17:11 -0700, Alexei Starovoitov wrote:

[...]

> >  enum bpf_features {
> > -       __MAX_BPF_FEAT = 0,
> > +       BPF_FEAT_RDONLY_CAST_TO_VOID = 0,
> > +       __MAX_BPF_FEAT = 1,
> 
> and the idea is to manually adjust it every time?!
> That's way too much churn.
> Either remove it or keep it without assignment.
> Just as __MAX_BPF_FEAT. Like similar thing in enum bpf_link_type.

I probably did not understand your previous message:

   > > +enum bpf_features {
   > > +       BPF_FEAT_RDONLY_CAST_TO_VOID = 0,
   > > +       BPF_FEAT_TOTAL,
   > 
   > I don't see the value of 'total', but not strongly against it.
   > But pls be consistent with __MAX_BPF_CMD, __MAX_BPF_MAP_TYPE, ...
   > Say, __MAX_BPF_FEAT ?
   > 
   > 
   > Also it's better to introduce this enum in some earlier patch,
   > and then always add BTF_FEAT_... to this enum
   > in the same patch that adds the feature to make
   > sure backports won't screw it up.
   > Another rule should be to always assign a number to it.


Specifically: "Another rule should be to always assign a number to it."
The BPF_FEAT_RDONLY_CAST_TO_VOID already had a number, so I assumed
you were talking about __MAX_BPF_FEAT.
What did you mean?