Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes:
> On Tue, Jan 24, 2023 at 5:18 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes:
>>
>> > The bpf developers adding new kfunc should assume that it's stable and proceed
>> > to use it in bpf progs and production applications.
>>
>> "Assume all kfuncs are stable" is fine by me, but that is emphatically
>> not what we have been saying thus far, quite the opposite...
>>
>> > The bpf maintainers will keep this stability promise. They obviously will not
>> > reap it out of the kernel on the whim, but they will nuke it if this kfunc
>> > will be in the way of the kernel innovation.
>>
>> ...and it is contradicted by this last bit. I mean "it's stable, but
>> we'll remove it if it's in the way" is not, well, stable.
>
> Schrodinger's kfuncs :)
Heh, yeah. There's a reason it's called Schrodinger's *uncertainty*
principle, though. Documenting it is about removing some of that
uncertainty so users of can actually know what to expect.
Otherwise, there is a subset of potential users who will shy away from
using kfuncs because it's perceived as "totally unstable, may change at
any time". Which is a shame, because there are many such users who could
benefit from using BPF.
So in other words, even if we don't commit to a stability promise I
think it's worth documenting expectations as precisely as we can.
[...]
>> > Back to deprecation...
>> > I think KF_DEPRECATED is a good idea.
>> > When kfunc will be auto emitted into vmlinux.h (or whatever other file)
>> > or shipped in libbpf header we can emit
>> > __attribute__((deprecated("reason", "replacement")));
>> > to that header file (so it's seen during bpf prog build) and
>> > start dmesg warn on them in the verifier.
>> > Kernel splats do get noticed. The users would have to act quickly.
>>
>> So how about documenting that bit? Something like:
>>
>> "We promise that kfuncs will not be removed without going through a
>> deprecation phase. The length of the deprecation will be proportional to
>> how long that kfunc has existed in the kernel, but will be no shorter
>> than XX kernel releases." ?
>
> That's not something we can promise.
> Take conntrack kfuncs. If netfilter folks decide to sunset
> conntrack tomorrow we won't be standing in their way.
Well, we could do one of two things:
- Make a promise to commit to the deprecation procedure and tell
subsystems not to add kfuncs unless they are OK with that (getting
suitable ACKs for the existing users first, of course)
or
- Document that core-BPF kfuncs won't go away without a deprecation
procedure, and have each subsystem using them document their own
policies.
I believe the latter is more in line what you and others have set as an
expectation when discussing this previously?
> On the other side the dynptr kfuncs are going to stay as-is for
> foreseeable future because they don't rely on other kernel
> subsystems to do the job.
> Both cases may still change if users themselves
> (after using it in prod) come back with reasons to change it.
>
> In the past the kernel devs were dictating the helper uapi to
> users and users had no option, but to shut up and use what's available.
> Now they will be able to use new apis and request changes.
> At that point it will be a set of users X vs a set of users Y.
> If ten users say that this kfunc sucks while one user
> wants to keep it as-is we will introduce another kfunc and
> will start deprecating the one that lost the vote.
"Lost the vote"? This seems like a can of worms (who can vote? how are
we counting them? etc). I think what you really mean here is something
like "maintainers will take into consideration the opinions of users of
the API and make a call as to whether the benefits of changing a kfunc
outweighs the costs"?
> The deprecation time window will depend on case by case
> considering maintenance cost, etc.
Right, that's not too far from what I proposed above. I still think it
would be useful to commit to a minimum number of releases, though.
Again, to set expectations.
-Toke
