On Thu 2022-03-31 08:02:19, Dave Chinner wrote: > On Wed, Mar 30, 2022 at 12:47:39PM -0400, Steven Rostedt wrote: > > On Wed, 30 Mar 2022 12:52:58 +0100 > > Chris Down <chris@xxxxxxxxxxxxxx> wrote: > > > > > The policy, as with all debugfs APIs by default, is that it's completely > > > unstable and there are no API stability guarantees whatsoever. That's why > > > there's no extensive documentation for users: because this is a feature for > > > kernel developers. > > > > > > 0: https://lwn.net/Articles/309298/ > > > > That article you reference states the opposite of what you said. And I got > > burnt by it before. Because Linus stated, if it is available for users, it > > is an ABI. > > > > From the article above: > > > > "Linus put it this way: > > > > The fact that something is documented (whether correctly or not) has > > absolutely _zero_ impact on anything at all. What makes something an ABI is > > that it's useful and available. The only way something isn't an ABI is by > > _explicitly_ making sure that it's not available even by mistake in a > > stable form for binary use. Example: kernel internal data structures and > > function calls. We make sure that you simply _cannot_ make a binary that > > works across kernel versions. That is the only way for an ABI to not form." > > > > IOW, files in debugfs are available for users, and if something is written > > that depends on it and it is useful, it becomes ABI. > > Yup, that's exactly what happened with powertop and the tracepoints > it used and why I pointed to it as is the canonical example of > information exposed from within debugfs unintentionally becoming > stable KABI.... To be sure that we are on the same page. Please, fix me if I am wrong. I am not that familiar with tracepoints. It is a rather complex feature. Each tracepoint has a name, arguments, fields, prints a message. I guess that the KABI aspects are: + name of the tracepoint + situation when they are triggered + names, type, and meaning of the parameters/fields + format and meaning or the printed messages In compare, a potential KABI aspects of a particular printk format (message) are: + situation when it is printed + format and meaning of the printed message They clearly have something in common. I guess that this causes the fear that the printk index feature might make convert a particular printk message into KABI. Note that the above summary is not talking about debugfs at all. Is it really debugfs what made tracepoints considered a KABI? Are tracepoints usable without debugfs? It is clear that the debugfs interface might be KABI on its own. There are many tools that use the interface to actually use the tracepoints. A change in the interface might break the tools. But it will be about the interface and not about the particular tracepoints. But I think that tracepoints are KABI even without the debugfs interface. We could create 10 different interfaces for tracepoints between the kernel and userspace. And all will break userspace if the functionality of a tracepoint is modified. I want to say. IMHO, it is is not debugfs what made KABI from tracepoints. I think that tracepoints can be considered KABI on its own. The tracepoints were created together with the debugfs interface. They would not make any sense without each other. This is not the case for printk() messages. They were always there. The printk index is not an interface for using the messages. It is like /proc/config.gz. The printk index describes what pieces are available in the kernel. IMHO, printk messages might already be considered KABI. There are clearly monitors checking particular messages. The printk index does not make any difference. Yes, it might be used to create a KABI checker. But a KABI checker does not create the KABI. KABI checkers exist only because something has already been considered KABI before. Or am I too naive or completely wrong, please? Best Regards, Petr
