On Thu, Nov 24, 2016 at 05:32:20PM +0000, Al Viro wrote: > On Wed, Nov 23, 2016 at 11:44:19AM -0700, Ross Zwisler wrote: > > Tracepoints are the standard way to capture debugging and tracing > > information in many parts of the kernel, including the XFS and ext4 > > filesystems. Create a tracepoint header for FS DAX and add the first DAX > > tracepoints to the PMD fault handler. This allows the tracing for DAX to > > be done in the same way as the filesystem tracing so that developers can > > look at them together and get a coherent idea of what the system is doing. > > It also has one hell of potential for becoming a massive nuisance. > Keep in mind that if any userland code becomes dependent on those - that's it, > they have become parts of stable userland ABI and are to be maintained > indefinitely. Don't expect "tracepoints are special case" to prevent that. I call bullshit just like I always do when someone spouts this "tracepoints are stable ABI" garbage. If we want to provide stable tracepoints, then we need to /create a stable tracepoint API/ and convert all the tracepoints that /need to be stable/ to use it. Then developers only need to be careful about modifying code around the /explicitly stable/ tracepoints and we avoid retrospectively locking the kernel implementation into a KABI so tight we can't do anything anymore.... Quite frankly, anyone that wants to stop us from adding/removing/changing tracepoints or the code that they are reporting information about "because ABI" can go take a long walk off a short cliff. Diagnostic tracepoints are not part of the stable ABI. End of story. > So treat anything you add in that manner as potential stable ABI > you might have to keep around forever. It's *not* a glorified debugging > printk. trace_printk() is the glorified debugging printk for tracing, not trace events. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
