From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19375 invoked by alias); 18 Dec 2008 09:21:23 -0000 Received: (qmail 19365 invoked by uid 22791); 18 Dec 2008 09:21:22 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_21,SARE_MSGID_LONG40,SPF_PASS X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_21,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.174) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 09:20:22 +0000 Received: by wf-out-1314.google.com with SMTP id 28so352763wfc.24 for ; Thu, 18 Dec 2008 01:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0uiiVwOQLw5SNm4MmDnXKc5YxRTyPotskG6sEMp+Z1M=; b=GESQbX1bzDr5uzRTv16qtxj2YjguLP7jd3Y6VRwjULP4WxlahpPrsR0Ye7MRBXskAR Mwjg8Ht0wQfW7pkMMd1yv9+gUu7XmB0pi1ry2ztg46KM9OyYLD2To3jrr3I4lEijZ3Mw iIpl3veHsXP0YFGzjti0gjVC3gic+PIOgWKPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=S3A/yPiUVVi4NjCwVx+UvGU603n12hbjvId7rma28z5BECMGeqXQL2HUdFtA2qbkSe Ey6N8zdCK+g712QYedyd2UEdIx7TKTeLrkEIY2rR1aZ290kNCxdwpHWGjLXF2Td6hhYq 41t8HLThaK+97KPbOWM8mez7egu0iWBQXn4B8= Received: by 10.142.84.11 with SMTP id h11mr239847wfb.337.1229592020913; Thu, 18 Dec 2008 01:20:20 -0800 (PST) Received: by 10.142.57.4 with HTTP; Thu, 18 Dec 2008 01:20:20 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 09:28:00 -0000 From: "Jun Koi" To: "jidong xiao" Subject: Re: Discussion at Linux Foundation Japan Symposium Cc: "Satoshi OSHIMA" , systemtap@sourceware.org, "=?ISO-2022-JP?B?IhskQko/Pj4bKEJAUmVkSGF0Ig==?=" , "=?ISO-2022-JP?B?GyRCNjZLXBsoQks=?=" , "Yumiko SUGITA" In-Reply-To: <4104961b0812180106n69d1e25ej269d36f39b5426b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <494A053D.4030808@hitachi.com> <4104961b0812180106n69d1e25ej269d36f39b5426b@mail.gmail.com> 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/msg00590.txt.bz2 On Thu, Dec 18, 2008 at 6:06 PM, jidong xiao wrote: > On Thu, Dec 18, 2008 at 4:57 PM, Jun Koi wrote: >> On Thu, Dec 18, 2008 at 5:09 PM, 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. >>> >>> 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. >>> >> >> How is it possible to do that without kernel debug info? Currently >> systemtap extracts lots of information on kernel layout from debug >> info, so I dont understand why we can survive without that. >> >> Thanks, >> Jun >> > But not every distribution contains kernel debuginfo packages, > therefore this makes many people not easy to use systemtap. > But my question is: how can we survive without debug info? In that case, we cannot tap into kernel anymore? (I guess tap on userspace still works) Thanks, Jun