From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16236 invoked by alias); 11 Jan 2009 16:29:51 -0000 Received: (qmail 16229 invoked by uid 22791); 11 Jan 2009 16:29:51 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_50,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Jan 2009 16:29:15 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n0BGTDi3023649 for ; Sun, 11 Jan 2009 11:29:13 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0BGTEtP031211 for ; Sun, 11 Jan 2009 11:29:14 -0500 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0BGTDHH008045; Sun, 11 Jan 2009 11:29:13 -0500 Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id n0BGTCpv027796; Sun, 11 Jan 2009 11:29:12 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id n0BGTCEL027795; Sun, 11 Jan 2009 11:29:12 -0500 Date: Sun, 11 Jan 2009 16:29:00 -0000 From: "Frank Ch. Eigler" To: Theodore Tso Cc: systemtap@sources.redhat.com Subject: Re: Discussion at Linux Foundation Japan Symposium Message-ID: <20090111162912.GC18407@redhat.com> References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081223211306.67D29FC3B7@magilla.sf.frob.com> <20081223223217.GW23723@mit.edu> <49518856.80907@redhat.com> <20090110024810.GL23869@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090110024810.GL23869@mit.edu> User-Agent: Mutt/1.4.1i 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: 2009-q1/txt/msg00089.txt.bz2 Hi - On Fri, Jan 09, 2009 at 09:48:10PM -0500, Theodore Tso wrote: > [...] > *) One of the really important reasons why SystemTap needs to move > runtime into the kernel is because especially for the community > distributions, [e.g. rawhide]. > If the SystemTap runtime is bundled with the kernel, then it's > much more likely that end users who want to use the daily kernel > RPM's will also be able to use SystemTap. That is one possible solution for this specific problem -- rawhide systemtap users who're unable/unwilling to build systemtap out of git occasoinally. (Remember that the recent 2.6.28 breakage took a few hours to fix.) Another solution would be for rawhide-style distributions to aggressively package systemtap snapshots into their development streams -- as some are doing already. (We could have semiautomated snapshots going straight into fedora rawhide too, and could increase the rate of minor releases.) > *) Systemtap needs to be adpted to use tracepoints, quickly [...] We will work on this very soon. > and eventually I suspect markers infrastructure will probably > disappear entirely since tracepoints are perceived as better and > as their replacement. (That would probably hurt lttng more than it would systemtap.) > Personally, I haven't had a chance to analyze them deeply enough > to know whether this is true, but it's clearly the long-term > direction. [...] I hope that before this long-term direction is brought into effect, someone does sit down and analyze the issue deeply enough. > SystemTap resisted making an effort get its runtime into the kernel, > now that the ftrace infrastructure is in the kernel, the principle of > not merging code that duplicates functionality means that this makes > Systemtap now needs to adapt what infrastructure did get merged for > its purposes, since it will be much more difficult get parallel > functionality merged into the kernel. You overestimate the amount of duplicated functionality. For modern kernels, systemtap uses the standard in-kernel relay API, with a tiny shim. (If the relay API were ever removed, systemtap would just switch to another existing API. Plain buffering is not rocket science.) - FChE