On Sun, Dec 10, 2023 at 9:04 PM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote: > [...] > > > > 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. > > > [...] > > > > > 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@xxxxxxxxx/
