Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules
Steven Rostedt <[email protected]> Fri, 11 Jul 2025 06:57:42 -0400
| Newsgroups | dev.linux.lists.tech-board-discuss,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
[ Adding the TAB to this as well ] On Fri, 11 Jul 2025 00:36:28 -0700 Christoph Hellwig <[email protected]> wrote: > On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote: > > Allow the unwind_user symbol to be used by GPL modules, for instance > > LTTng. > > I don't see a LTTng submission or any other user in this series. > So the usual prohibition against adding unused exports applies here > as usual. I want to bring up this discussion. I understand there's a policy not to add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel proper. My question is, does this policy have to be draconian? The LTTng project and specifically its maintainer Mathieu has a long history of working along side of the Linux kernel and actively adding enhancements to the code. This is not an Nvidia or VMware situation where the modules add special secret sauce that they do not want to share. This is a long standing kernel contributor and maintainer that has proved himself time and time again to be an asset to the Linux kernel community. It's not even that LTTng wants to be out of tree. There's been several attempts to get LTTng merged. But they all failed due to disagreements in approaches and other aspects of the design. With perf and ftrace already in the kernel which focus toward helping kernel developers debug their issue, several maintainers do not see the point of LTTng. But LTTng focuses more on non kernel developers. Mathieu and I have come to a conclusion that LTTng and ftrace have two different audiences. And we actively work with each other to improve both ftrace and LTTng. LTTng was redesigned to work as a very non-intrusive external kernel module that could be ported to newer kernels without much pain. This approach has worked for both Mathieu and the kernel maintainers for several years. It is not because Mathieu doesn't want LTTng in the kernel that is keeping it out of the tree. He would very much like it in-tree! LTTng is not in the kernel because the kernel maintainers themselves have been blocking it. I do not feel that we should be also add the extra burden to prevent any call it could use from being EXPORT_SYMBOL_GPL(). Mathieu has been very helpful in the work to develop this deferred unwind code that will help ftrace, perf and BPF. I would also like it to help LTTng. The only way to do so is to have an EXPORT_SYMBOL_GPL() for it. Now you can argue that we need to get LTTng into mainline before it can use this new work that the maintainer of LTTng has been very involved in to develop. But that would probably take a long time and from past experiences, may fail completely. So for now, I am saying that we give LTTng an exception to the rule that functions can not be EXPORT_SYMBOL_GPL() unless there's a in-tree kernel module that requires it. -- Steve