On Sun, Dec 10, 2023 at 9:04 PM Akihiko Odaki [off-list ref] wrote:

[...]

quoted

I don't think we can provide stability guarantees before seeing something
being used in the field. How do we know it will be useful forever? If a
couple years later, there is only one person using it somewhere in the
world, why should we keep supporting it? If there are millions of virtual
machines using it, why would you worry about it being removed?

I have a different opinion about providing stability guarantees; I
believe it is safe to provide such a guarantee without actual use in a
field. We develop features expecting there are real uses, and if it
turns out otherwise, we can break the stated guarantee since there is no
real use cases anyway. It is fine even breaking UAPIs in such a case,
which is stated in Documentation/admin-guide/reporting-regressions.rst.

So I rather feel easy about guaranteeing UAPI stability; we can just
guarantee the UAPI-level stability for a particular kfunc and use it
from QEMU expecting the stability. If the feature is found not useful,
QEMU and the kernel can just remove it.

It appears that we more or less agree that this feature may not be
something we will support forever.

I'm more concerned about the other case, which means that there will be
wide uses of this feature. A kernel developer may assume the stability
of the interface is like one of kernel internal APIs
(Documentation/bpf/kfuncs.rst says kfuncs are like EXPORT_SYMBOL_GPL)
and decide to change it, breaking old QEMU binaries and that's something
I would like to avoid.

Regarding the breakage scenario, I think we can avoid the kfuncs removal
just by saying "we won't remove them". I'm more worried the case that a
change in the BPF kfunc infrastucture requires to recompile the binary.

So, in short, I don't think we can say "kfuncs are like
EXPORT_SYMBOL_GPL" and "you can freely use kfuncs in a normal userspace
application like QEMU" at the same time.

quoted

[...]

quoted

I would recommend you give option 2 a try and share the code. This is
probably the best way to move the discussion forward.

I'd like to add a documentation change to say the added kfuncs are
exceptional cases that are not like EXPORT_SYMBOL_GPL in that case. Will
it work?

It will not.

The BPF community had a lot of discussions about the stability of BPF APIs, for
example in [1]. Therefore, this is not a light decision.

AFAICT, what is being proposed in this RFC is way less stable than many kfuncs
we added recently. We are not changing the stability guarantee for this. Let's
invest our time wisely and work on more meaningful things, for example, a
prototype that may actually get accepted.

Thanks,
Song

[1] https://lore.kernel.org/bpf/20221207205537.860248-1-joannelkoong@gmail.com/ (local)