From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 1/2] vfs: make fcheck_files() an exported functions Date: Sun, 10 Feb 2013 00:18:12 +0000 Message-ID: <20130210001811.GH4503@ZenIV.linux.org.uk> References: <20130109170105.GM3926@htj.dyndns.org> <20130209192447.GE2875@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Steven Rostedt , chavey@google.com, Andrew Morton To: Tejun Heo Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:57572 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752383Ab3BJASO (ORCPT ); Sat, 9 Feb 2013 19:18:14 -0500 Content-Disposition: inline In-Reply-To: <20130209192447.GE2875@htj.dyndns.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 > > Cc: Steven Rostedt > > Cc: Al Viro > > --- > > 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.