On Sat, Feb 09, 2013 at 11:24:47AM -0800, Tejun Heo wrote: > (cc'ing Andrew) > > On Wed, Jan 09, 2013 at 09:01:05AM -0800, Tejun Heo wrote: > > We want to add a trace point to fcheck_files() but macros and inline > > functions defined in header files can't have tracing points. Move > > fcheck_files() to fs/file.c and make it a proper function. > > > > A lot of high-frequency fcheck*() users are inside fs/file.c, and, to > > reduce the effect of this change, the new exported function is also > > declared inline. > > > > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> > > Cc: Steven Rostedt <rostedt@xxxxxxxxxxx> > > Cc: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > --- > > These two patches add vfs_fcheck tracepoint. Making fcheck_files() a > > function isn't optimal but given the tracepoint restriction I can't > > think of a better way. The TP is currently in use in google to allow > > ioblame to track who's accessing which file which in turn is used to > > approximately associate IOs with files. I'm working to upstream the > > rest of ioblame. > > 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: 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. -- 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
