Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752420AbZJTOic (ORCPT ); Tue, 20 Oct 2009 10:38:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751882AbZJTOib (ORCPT ); Tue, 20 Oct 2009 10:38:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60577 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136AbZJTOia (ORCPT ); Tue, 20 Oct 2009 10:38:30 -0400 Message-ID: <4ADDCB56.60700@redhat.com> Date: Tue, 20 Oct 2009 10:38:14 -0400 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Ingo Molnar CC: Frederic Weisbecker , Steven Rostedt , lkml , Thomas Gleixner , Arnaldo Carvalho de Melo , Mike Galbraith , Paul Mackerras , Peter Zijlstra , Christoph Hellwig , Ananth N Mavinakayanahalli , Jim Keniston , "Frank Ch. Eigler" , "H. Peter Anvin" , systemtap , DLE Subject: Re: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes References: <20091017000711.16556.69935.stgit@dhcp-100-2-132.bos.redhat.com> <20091017080203.GA4155@elte.hu> <20091017103427.GA31238@elte.hu> <4ADAAF50.9040604@redhat.com> <20091019075103.GF17960@elte.hu> <20091019110055.GA5549@nowhere> <20091019112125.GA12829@elte.hu> <4ADCC348.2020800@redhat.com> <20091020065055.GL8550@elte.hu> In-Reply-To: <20091020065055.GL8550@elte.hu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2031 Lines: 52 Ingo Molnar wrote: >>> The point is to prefer intuitive, non-mechanic, fundamentally human >>> expressions of information above mechanic ones (absolute line numbers, >>> addresses, ways of probing, etc.) - and to have a rich variety of them. >>> >>> String based pattern matching and intuitive syntax that reuses existing >>> paradigms of arithmetics and pattern-matching is good - limited syntax >>> and extra, arbitrary syntactic hoops to jump through is bad. >>> >>> If we provide all that, people will start using this stuff - and i'd >>> only like to merge this upstream once it's clear that people like me >>> will (be able to) use this facility for ad-hoc probe insertion. >>> >>> In other words: this facility has to 'live within' our source code and >>> has to be able to interact with it on a very broad basis - for it to be >>> maximally useful for everyday development. >> >> Hmm, so you mean perf-probe should work with source-code? Without >> source code (but with debuginfo), maybe we can't use string matching, >> is that OK? > > Well most forms of debuginfo embedd the full source code in the > debuginfo, right? If it's not there (or we dont know where it is) then > we cannot use it, obviously. Um, actually debuginfo doesn't have the full source code, but has the source file path. So, only if there are source files, we can use string-based matching. Even if there are no source files, that means users can't change their kernel:-). So we don't care about kernel-version dependency. > But we obviously want the whole 'perf probe' workflow to primarily > operate on source code - we are humans. Sure :-) Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhiramat@redhat.com -- 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/