Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933147Ab0KQOA3 (ORCPT ); Wed, 17 Nov 2010 09:00:29 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:42578 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752871Ab0KQOA2 (ORCPT ); Wed, 17 Nov 2010 09:00:28 -0500 Date: Wed, 17 Nov 2010 15:00:02 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: "Ted Ts'o" , Thomas Gleixner , LKML , Linus Torvalds , Andrew Morton , Steven Rostedt , Arjan van de Ven , Arnaldo Carvalho de Melo , Frederic Weisbecker , Masami Hiramatsu , Tom Zanussi , Mathieu Desnoyers , Li Zefan , Jason Baron , "David S. Miller" , Christoph Hellwig , Pekka Enberg , Lai Jiangshan , Eric Dumazet Subject: Re: [ANNOUNCE] New utility: 'trace' Message-ID: <20101117140002.GH27063@elte.hu> References: <20101117013700.GA3290@thunk.org> <20101117132404.GF27063@elte.hu> <1290001128.2109.785.camel@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290001128.2109.785.camel@laptop> User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1050 Lines: 28 * Peter Zijlstra wrote: > On Wed, 2010-11-17 at 14:24 +0100, Ingo Molnar wrote: > > > What about the filtering and other general features/functionality of > > > ftrace? Is the anticipation that this will be ported over to perf? > > > What about things like blktrace? > > > > Yeah, i'd love to see all that available. Filtering is available already on the > > kernel perf event side and could be added as an option. > > Except I utterly detest the existing filter code.. it runs _after_ we do all the > hard work and then makes us roll back when it decides we shouldn't output after > all. > > But yes, it is functional. I suspect that is what matters mostly - unless you think that it's impossible to have a sane implementation of it, if the users come. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/