Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753242Ab1COF1d (ORCPT ); Tue, 15 Mar 2011 01:27:33 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:58715 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751841Ab1COF1a (ORCPT ); Tue, 15 Mar 2011 01:27:30 -0400 Date: Tue, 15 Mar 2011 10:51:33 +0530 From: Srikar Dronamraju To: Thomas Gleixner Cc: "Frank Ch. Eigler" , Andrew Morton , int-list-linux-mm@kvack.org, linux-mm@kvack.org, Peter Zijlstra , Ingo Molnar , Steven Rostedt , Arnaldo Carvalho de Melo , Linus Torvalds , Masami Hiramatsu , Christoph Hellwig , Ananth N Mavinakayanahalli , Andi Kleen , Oleg Nesterov , Jim Keniston , SystemTap , LKML , "Paul E. McKenney" Subject: Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes Message-ID: <20110315052133.GT24254@linux.vnet.ibm.com> Reply-To: Srikar Dronamraju References: <20110314133403.27435.7901.sendpatchset@localhost6.localdomain6> <20110314163028.a05cec49.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Content-Scanned: Fidelis XPS MAILER Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2998 Lines: 82 Hi Thomas, > > > > > [...] How do you envisage these features actually get used? > > > > Patch #20/20 in the set includes an ftrace-flavoured debugfs frontend. > > And you really think that: > > # cd /sys/kernel/debug/tracing/ > > # cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp > 00400000-0048a000 r-xp 00000000 08:03 130904 /bin/zsh > > # objdump -T /bin/zsh | grep -w zfree > 0000000000446420 g DF .text 0000000000000012 Base zfree > > # echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events > > # cat uprobe_events > p:uprobes/p_zsh_0x46420 /bin/zsh:0x0000000000046420 > > > TODO: Documentation/trace/uprobetrace.txt > > without a reasonable documentation how to use that is a brilliant > argument? We had a fairly decent documentation for uprobes and uprobetracer. But that had to be changed with the change in underlying design of uprobes infrastructure. Since uprobetrace is one the user interface, I plan to document it soon. However it would be great if we had inputs on how we should be designing the syscall. > > > Previous versions of the patchset included perf front-ends too, which > > are probably to be seen again. > > Ahh, probably. What does that mean? > > And if that probably happens, what interface is that supposed to > use? > > The above magic wrapped into perf ? For the initial perf probe thing, yes it would be a wrapper over uprobe_tracer. That is because we can reuse most of the current perf probe and we could prototype and show users what all can be achieved. However we plan to make perf probe depend on the syscall when the syscall takes shape. > > Or some sensible implementation ? Would syscall based perf probe implementation count as a sensible implementation? My current plan was to code up the perf probe for uprobes and then draft a proposal for how the syscall should look. There are still some areas on how we should be allowing the filter, and what restrictions we should place on the syscall defined handler. I would like to hear from you and others on your ideas for the same. If you have ideas on doing it other than using a syscall then please do let me know about the same. I know that getting the user interface right is very important. However I think it kind of depends on what the infrastructure can provide too. So if we can decide on the kernel ABI and the underlying design (i.e can we use replace_page() based background page replacement, Are there issues with the Xol slot based mechanism that we are using, etc), we can work towards providing a stable User ABI that even normal users can use. For now I am concentrating on getting the underlying infrastructure correct. Please let me know your thoughts. -- Thanks and Regards Srikar -- 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/