On Sun, Nov 27, 2016 at 04:58:43PM -0800, Linus Torvalds wrote: > On Sun, Nov 27, 2016 at 2:42 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > And that's exactly why we need a method of marking tracepoints as > > stable. How else are we going to know whether a specific tracepoint > > is stable if the kernel code doesn't document that it's stable? > > You are living in some unrealistic dream-world where you think you can > get the right tracepoint on the first try. No, I'm under no illusions that we'd get stable tracepoints right the first go. I don't care about how we stabilise stable tracepoints, because nothing I maintain will use stable tracepoints. However, I will point out that we have /already solved these ABI development problems/. $ ls Documentation/ABI/ obsolete README removed stable testing $ Expands this to include stable tracepoints, not just sysfs files. New stable stuff gets classified as "testing" meaning it is supposed to be stable but may change before being declared officially stable. "stable" is obvious, are "obsolete" and "removed". > So there is no way in hell I would ever mark any tracepoint "stable" > until it has had a fair amount of use, and there are useful tools that > actually make use of it, and it has shown itself to be the right > trace-point. > > And once that actually happens, what's the advantage of marking it > stable? None. It's a catch-22. Before it has uses and has been tested > and found to be good, it's not stable. And after, it's pointless. And that "catch-22" is *precisely the problem we need to solve*. Pointing out that there's a catch-22 doesn't help anyone - all the developers that are telling you that they really need a way to mark stable tracepoints already understand this catch-22 and they want a way to avoid it. Being able to either say "this is stable and we'll support it forever" or "this will never be stable so use at your own risk" is a simple way of avoiding the catch-22. If an unstable tracepoint is useful to applications *and it can be implemented in a maintainable, stable form* then it can go through the process of being made stable and documented in Documentation/ABI/stable. Problem is solved, catch-22 is gone. All we want is some method of making a clear, unambiguous statement about the nature of a specific tracepoint and a process for transitioning a tracepoint to a stable, maintainable form. We do it for other ABI interfaces, so why can't we do this for tracepoints? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
