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?
