From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22843 invoked by alias); 5 Aug 2010 10:34:52 -0000 Received: (qmail 22835 invoked by uid 22791); 5 Aug 2010 10:34:51 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,TVD_RCVD_SPACE_BRACKET X-Spam-Check-By: sourceware.org Received: from mail4.hitachi.co.jp (HELO mail4.hitachi.co.jp) (133.145.228.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Aug 2010 10:34:44 +0000 Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 6883B33CC2; Thu, 5 Aug 2010 19:34:42 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id o75AYgoW022915; Thu, 5 Aug 2010 19:34:42 +0900 Received: from hitachi.com (mfbcchk3.hitachi.co.jp [10.201.6.152]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id o75AScnY018997; Thu, 5 Aug 2010 19:34:42 +0900 Received: from vshuts3.hitachi.co.jp ([vshuts3.hitachi.co.jp [10.201.6.72]]) by mfbcchk3.hitachi.co.jp with RELAY id o75AYfrR021447 ; Thu, 5 Aug 2010 19:34:42 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp (unknown [133.144.7.20]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id EFA8377426C; Thu, 5 Aug 2010 19:34:40 +0900 (JST) Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id o75AYZ2P020205; Thu, 5 Aug 2010 19:34:40 +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 M2010080519343930379 ; Thu, 05 Aug 2010 19:34:39 +0900 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id 3478312551F; Thu, 5 Aug 2010 19:34:39 +0900 (JST) Message-ID: <4C5A93BF.5080802@hitachi.com> Date: Thu, 05 Aug 2010 10:34:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Wielaard Cc: Srikar Dronamraju , 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> <1280927213.2974.58.camel@springer.wildebeest.org> In-Reply-To: <1280927213.2974.58.camel@springer.wildebeest.org> Content-Type: text/plain; charset=UTF-8 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/msg00186.txt.bz2 Mark Wielaard wrote: > On Wed, 2010-08-04 at 15:06 +0530, 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 don't know if these users and kernel hackers hang out at the same > conferences. But there have been some blog posts by people using > systemtap for these kind of static markers in gnome libraries: > http://tecnocode.co.uk/2010/07/13/reference-count-debugging-with-systemtap/ > http://blogs.gnome.org/alexl/2010/01/04/tracing-glib/ Hm, these are very interesting stories. We should let kernel people know that application people already start using systemtap/dtrace in there developing process. >>> The kernel maintainers can make our lives easier by letting us upstream >>> more stuff that we can then reuse. But if not, we can upstream and still >>> carry our own copy if necessary. That is far from ideal, but if it is >>> the only option, at least the user experience wouldn't be worse than >>> what we have now. But I hope we can convince them otherwise of course. >>> >> But Mark, that may not provide the out-of-box experience that most >> of the users esp the first timers would look for. And it would >> certainly cap our users. > > I am not saying it is ideal. But it wouldn't be worse than the current > experience. If the kernel maintainers really don't want to export the > functionality and we don't want to ship a parallel module of our own, > then we could also use the exported kallsyms support in newer kernels to > call the function addresses directly. That might actually be slightly > nicer for the user, although a bit more fragile. Uh, that's really really the last resort. We have to talk about what is the best way for users with kernel people and try hard to find out how to compromise as far as we can. Thank you, > > Cheers, > > Mark > -- Masami HIRAMATSU 2nd Research Dept. Hitachi, Ltd., Systems Development Laboratory E-mail: masami.hiramatsu.pt@hitachi.com