[ Added Ingo and Linus ] On Tue, 2013-02-12 at 09:41 -0800, Tejun Heo wrote: > Hey, Al. > > On Sun, Feb 10, 2013 at 12:18:12AM +0000, Al Viro wrote: > > > Andrew, can you please pick up these two patches? They were posted a > > > month ago and at least nobody seems violently against them. The > > > original patches are, > > > > Consider *any* tracepoints in that area blanketly NAKed. Sorry, I thought > > I made it clear, but just in case: > > Heh, this is the first time I hear about it. > > > As far as I'm concerned, *the* *only* interface stability warranties in VFS > > are those for syscalls. Which means that no tracepoints are going to be > > acceptable there. End of story. > > I see, it's about API stability. This TP is expected to be used by > internal tracer to approxmiately match generated IOs to specific > files, so at least the proposed usage is inside the kernel. I suppose > there's no way to mark TPs internal, Steven? We discussed this a couple of years ago at kernel summit, but for various reasons it never got anywhere. https://lkml.org/lkml/2010/11/16/606 Perhaps the way to do this is to have certain tracepoints only appear with a kernel parameter. Something like "enable_debug_tracepoints", where distros will not have it enabled by default (the word "debug" should scare them). And thus, tools should never use them. But for those that need to debug systems, the kernel parameter can be added, and these tracepoints will "magically" appear. I mean, do we have to support an ABI that requires a kernel parameter set in order to use it? Actually, debug didn't scare them enough for debugfs, maybe the parameter should be called: "enable_unstable_tracepoints" That would be even scarier. Or have it be "enable_tracepoints_but_do_not_expect_them_to_exist", but that wastes up too much of the kernel parameter text. Hmm, this should be pretty ease to write up. Think that would work? -- Steve > > Anyways, I haven't looked at the tracer code for a while, and am not > sure whether the information can be acquired differently. Will take > another look. > > Thanks. > -- 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