From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19279 invoked by alias); 5 Aug 2010 10:26:25 -0000 Received: (qmail 19259 invoked by uid 22791); 5 Aug 2010 10:26:23 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_20,TVD_RCVD_SPACE_BRACKET X-Spam-Check-By: sourceware.org Received: from mail7.hitachi.co.jp (HELO mail7.hitachi.co.jp) (133.145.228.42) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Aug 2010 10:26:18 +0000 Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id E25E037AC5; Thu, 5 Aug 2010 19:26:15 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id o75AQFab005256; Thu, 5 Aug 2010 19:26:15 +0900 Received: from hitachi.com (mfbcchk2.hitachi.co.jp [10.201.6.151]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id o754tek7009985; Thu, 5 Aug 2010 19:26:15 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfbcchk2.hitachi.co.jp with RELAY id o75AQEfF010543 ; Thu, 5 Aug 2010 19:26:15 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp (unknown [133.144.7.20]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 7F7A68B0116; Thu, 5 Aug 2010 19:26:14 +0900 (JST) Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id o75AQEsW018345; Thu, 5 Aug 2010 19:26:14 +0900 Received: from sdl99w.sdl.hitachi.co.jp ([133.144.14.250]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2010080519261330357 ; Thu, 05 Aug 2010 19:26:13 +0900 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id A8DF112550A; Thu, 5 Aug 2010 19:26:11 +0900 (JST) Message-ID: <4C5A91C3.4090306@hitachi.com> Date: Thu, 05 Aug 2010 10:26:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Srikar Dronamraju Cc: Mark Wielaard , systemtap@sources.redhat.com, Satoshi Oshima Subject: Re: [RFC] SystemTap future direction References: <4C58F852.7030103@hitachi.com> <1280907560.24123.26.camel@springer.wildebeest.org> <20100804093615.GB28212@linux.vnet.ibm.com> In-Reply-To: <20100804093615.GB28212@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-FMFTCR: RANGEC X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00185.txt.bz2 Srikar Dronamraju wrote: >> Yes. I was at GUADEC last week and was happily surprised to meet >> multiple Gnome hackers who were happy systemtap users. glib and gobject >> have their own static markers (dtrace compatible) and tapsets now. >> > > This is nice to hear. Probably would it help if some of these folks > talk about how they used SystemTap with some key kernel developers > whenever they meet let say in conferences like say Plumbers, end > user summits etc ?? I'm asking some systemtap users in Japan to join us at LinuxCon Japan, tracing track. I found some PostgreSQL developers who are using systemtap for profiling transactions instead of Dtrace ;) So, we may be able to convince kernel people if we can bring systemtap users voice to them. If they know not only kernel developers but also application developers and users use systemtap, they need to consider features for those users. >>> I'd like to suggest some directions here; >>> >>> - Merge runtime and module-source generator into linux kernel. >>> This will requires rewriting whole of systemtap code from C++ to >>> C or other LL (perl or python) >> If that requires rewriting the whole translator that seems very >> unattractive. The translator is just the script parser and translator, >> so I don't see why it matters what language it is written in. But >> merging some of the runtime, specifically the utrace/task-finder code so >> it can be reused by others to get better user space task/process >> observability seems like a nice thing to have. >> > > I think the task-finder would be gated by utrace. > I am working on a file based uprobing stuff that provides very > minimal task-finder like features. Nice! :) Thank you, -- Masami HIRAMATSU 2nd Research Dept. Hitachi, Ltd., Systems Development Laboratory E-mail: masami.hiramatsu.pt@hitachi.com