From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17546 invoked by alias); 18 Dec 2008 08:10:28 -0000 Received: (qmail 17535 invoked by uid 22791); 18 Dec 2008 08:10:27 -0000 X-SWARE-Spam-Status: No, hits=4.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_21,J_CHICKENPOX_66 X-Spam-Status: No, hits=4.2 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_21,J_CHICKENPOX_66 X-Spam-Check-By: sourceware.org Received: from mail9.hitachi.co.jp (HELO mail9.hitachi.co.jp) (133.145.228.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 08:09:43 +0000 Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 69AFE37C8C for ; Thu, 18 Dec 2008 17:09:41 +0900 (JST) Received: from MFILTER-S5.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id mBI89fVF014446; Thu, 18 Dec 2008 17:09:41 +0900 Received: from vshuts2.hitachi.co.jp (unverified) by MFILTER-S5.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 18 Dec 2008 17:09:41 +0900 X-AuditID: 0ac90647-adefaba000000f8c-79-494a0545b998 Received: from hsdlgw92.sdl.hitachi.co.jp (unknown [133.144.7.20]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 28CCB8B0234; Thu, 18 Dec 2008 17:09:41 +0900 (JST) Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id mBI89XAN010558; Thu, 18 Dec 2008 17:09: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 M2008121817094019937 ; Thu, 18 Dec 2008 17:09:40 +0900 Received: from [127.0.0.1] (IDENT:U2FsdGVkX18qavfxxLScnbmHOHoHDvaq57mjNz0jGZU@localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (8.13.1/3.7W04031011) with ESMTP id mBI89Xo3003725; Thu, 18 Dec 2008 17:09:33 +0900 Message-ID: <494A053D.4030808@hitachi.com> Date: Thu, 18 Dec 2008 08:33:00 -0000 From: Satoshi OSHIMA User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: systemtap@sourceware.org Cc: =?ISO-2022-JP?B?IhskQko/Pj4bKEJAUmVkSGF0Ig==?= , =?ISO-2022-JP?B?GyRCNjZLXBsoQks=?= , Yumiko SUGITA Subject: Discussion at Linux Foundation Japan Symposium Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== 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/msg00586.txt.bz2 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. 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. (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. (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. To do this, systemtap project might need more ambassadors for kernel community. In addition, since criticisms of systemtap occur in events sponsored by Linux Foundation, systemtap project ambassadaor(s) should talk with Linux Foundation people(Andrew Morton, Ted, James). I hope my suggestion help you to understand the current developers feelings. Regards, Satoshi Oshima