From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25877 invoked by alias); 18 Dec 2008 15:35:55 -0000 Received: (qmail 25865 invoked by uid 22791); 18 Dec 2008 15:35:54 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_21,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_21,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 15:35:04 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBIFYxDl025258; Thu, 18 Dec 2008 10:34:59 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBIFYwbK005760; Thu, 18 Dec 2008 10:34:58 -0500 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBIFYvJF013786; Thu, 18 Dec 2008 10:34:57 -0500 Message-ID: <494A6DA3.7010604@redhat.com> Date: Thu, 18 Dec 2008 15:41:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: Satoshi OSHIMA CC: systemtap@sourceware.org, =?ISO-2022-JP?B?GyRCNjZLXBsoQks=?= , Yumiko SUGITA Subject: Re: Discussion at Linux Foundation Japan Symposium References: <494A053D.4030808@hitachi.com> In-Reply-To: <494A053D.4030808@hitachi.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 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: 2008-q4/txt/msg00600.txt.bz2 Hi Satoshi, Thank you for reporting! Satoshi OSHIMA wrote: > Hi all, > > Long time no see and sorry for my late report. > > I attended 9th Linux Foundation Japan Symposium and > discussed on issues of systemtap project with Ted Ts'o, > James Bottomley and Jonathan Corbet. FYI, we also discuss this topic on below bugzilla. http://sourceware.org/bugzilla/show_bug.cgi?id=7042 There are links to videos of the symposium on that bugzilla. > In my understanding, they demand the following things: > > (1) Follow upstream first > > Utrace and uprobe features are currently available only > on Fedora and Red Hat Enterprise Linux, since those > patches are not merged into upstream kernel yet. > > my suggestion: > > To reduce complaints of upstream kernel developers, > systemtap project may need to postpone adding new > uprobe features until getting utrace (and uprobe) > patch set accepted in mainline. > > > (2) Maintain tapset > > Systemtap users (including kernel developers) get > frustrated because tapsets often do not work on > the latest kernel. Moreover, sometimes users > have to fix the tapset incompatibility of kernels. > > my suggestion: > > If systemtap procjet can fix this kind of incompatibilities > within a few hours or days as Myths about systemtap > on the wiki claims, releasing new systemtap minor release > tarball for each upstream kernel release would help users. Agreed, We have a weekly snapshot for it. however, that means it could delay 1 week. And also, we should provide which release can work on the latest kernel. > (3) Make no debuginfo version > > Systemtap always requires kernel debuginfo to use. > Unfortunately, it is hard for users of some distributions > to have debuginfo. > > my suggestion: > > If systemtap has a build option to make no debuginfo version, > this complain will be reduced. I know we had had it before. > We should provide it again. As Prasad said, systemtap had supported no-dwarf mode, however, currently it is disabled (due to uprobe issue?). I strongly recommend to re-enable it only for kernel-space probes as soon as possible. > (4) Have conversations frequently with Kernel Community > > I understand that Frank has tried to communicate with upstream > kernel community. However, it seems that developers of upstream > kernel feel it is not enough. > > my suggestion: > > I know that systemtap is a bit different from other part of > the kernel. Usual kernel subsystem maintainers are chosen > on activities in lkml. On the other hand, systemtap maintainer's > activities are invisible for almost all of the kernel developers. > > This may be one of the reasons of their frastration. > To solve this problem, we should periodically make announcements > of systemtap update and require questions or comments. >From Linux foundation video, I think we also would better work with some kernel (subsystem) maintainers, and ask them what they need to use systemtap easy. -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com