From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 676 invoked by alias); 23 Jul 2008 22:14:27 -0000 Received: (qmail 667 invoked by uid 22791); 23 Jul 2008 22:14:26 -0000 X-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63,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.31) with ESMTP; Wed, 23 Jul 2008 22:14:09 +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 m6NME4wK019315; Wed, 23 Jul 2008 18:14:04 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [10.16.255.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6NME3Oo007922; Wed, 23 Jul 2008 18:14:03 -0400 Received: from [10.16.10.29] (vpn-10-29.bos.redhat.com [10.16.10.29]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m6NME2cO007543; Wed, 23 Jul 2008 18:14:02 -0400 Message-ID: <4887ACD5.1020202@redhat.com> Date: Wed, 23 Jul 2008 22:14:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: Arjan van de Ven , Rik van Riel , James Bottomley , linux-kernel , systemtap@sourceware.org Subject: Re: systemtap & backward compatibility, was Re: [RFC] systemtap: begin the process of using proper kernel APIs References: <487E8CE4.70105@redhat.com> <1216259391.3358.85.camel@localhost.localdomain> <1216304290.5515.11.camel@localhost.localdomain> <1216313914.5515.25.camel__21144.9282979176$1216314027$gmane$org@localhost.localdomain> <1216325546.5515.63.camel@localhost.localdomain> <20080717202634.GI18295@redhat.com> <1216328769.5515.78.camel@localhost.localdomain> <20080717213355.GJ18295@redhat.com> <20080722140015.37628ea4@bree.surriel.com> <20080723150434.GC11191@redhat.com> <20080723082856.334f9c17__2909.60763018138$1216827051$gmane$org@infradead.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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-q3/txt/msg00304.txt.bz2 Hi Frank, Frank Ch. Eigler wrote: > Arjan van de Ven writes: [...] >> (and when it's seen it gets a rather luke warm reception, but that's >> a different story). > > I hope the backward compatibility issue, as it stands today, helps > explain the reasons for the current deal with kprobes. I understood that the current deal with kprobes is also for integrating user probe logic and kernel probe logic. Obviously, it is hard uprobe to provide same symbol_name interface, because it requires to access(and analyze) userspace symbol information from kernel. > In the interim (before we come up with a way of moving more > kernel-coupled systemtap code into kernel.org/git), would y'all > consider an arrangement? Those of you who care about systemtap, and > are intending to make an incompatible kernel/module interface change, > please run the systemtap testsuite before & after. If it regresses, > send us a note or a patch. If practical, we'll integrate it (and add > any backward-compatibility hacks if needed) into systemtap. Hmm, I think it's very costly way for both of kernel developers and systemtap developers. >From the long term of viewpoint, I think it's better (less costly) to merge systemtap runtime/tapset into upstream kernel and maintain it. Then, we can stabilize its API by ourselves on upstream. Since it reduces the catchup/maintenance cost and it enables users to use stap on upstream kernel, I think it is benefit for both. Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com