On Fri, Nov 25, 2016 at 11:51:26AM -0800, Linus Torvalds wrote: > On Thu, Nov 24, 2016 at 11:37 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > My impression is that nobody (at least kernel-side) wants them to be > > a stable ABI, so long as nobody in userland screams about their code > > being broken, everything is fine. As usual, if nobody notices an ABI > > change, it hasn't happened. The question is what happens when somebody > > does. > > Right. There is basically _no_ "stable API" for the kernel anywhere, > it's just an issue of "you can't break workflow for normal people". > > And if somebody writes his own trace scripts, and some random trace > point goes away (or changes semantics), that's easy: he can just fix > his script. Tracepoints aren't ever going to be stable in that sense. > > But when then somebody writes a trace script that is so useful that > distros pick it up, and people start using it and depending on it, > then _that_ trace point may well have become effectively locked in > stone. 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? And how are we going to know why it's considered stable if there isn't a commit message that explains why it was made stable? > We do have filesystem code that is just disgusting. As an example: > fs/afs/ tends to have these crazy "_enter()/_exit()" macros in every > single function. If you want that, use the function tracer. That seems > to be just debugging code that has been left around for others to > stumble over. I do *not* believe that we should encourage that kind of > "machine gun spray" use of tracepoints. Inappropriate use of tracepoints is a different problem. The issue here is getting rid of the uncertainty caused by the handwavy "tracepoints a mutable until someone, somewhere decides to use it in userspace" policy. > But tracing actual high-level things like IO and faults? I think that > makes perfect sense, as long as the data that is collected is also the > actual event data, and not so much a random implementation issue of > the day. IME, a tracepoint that doesn't expose detailed context specific information isn't really useful for complex problem diagnosis... 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
