From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10314 invoked by alias); 1 Nov 2010 20:54:03 -0000 Received: (qmail 10307 invoked by uid 22791); 1 Nov 2010 20:54:02 -0000 X-SWARE-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Nov 2010 20:53:57 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PD1O6-0005u0-KL for systemtap@sources.redhat.com; Mon, 01 Nov 2010 21:53:54 +0100 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Nov 2010 21:53:54 +0100 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Nov 2010 21:53:54 +0100 To: systemtap@sources.redhat.com From: Grant Edwards Subject: Re: documentation for user-space usage? Date: Mon, 01 Nov 2010 20:54:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: slrn/pre0.9.9-102 (Linux) 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: 2010-q4/txt/msg00148.txt.bz2 On 2010-11-01, Frank Ch. Eigler wrote: > > grant.b.edwards wrote: > >> [...] >> Assuming utrace/uprobes gets ported to ARM, does such a trace events >> involve a context switch to kernel-mode and then back to user-mode? > > Yes. That might be a concern if it affects timings too much. If we roll our own, the plan would be to keep it purely user-space in order to avoid the impact of context switching when logging is enabled. >> [...] I'm using ARM9. Utrace support patches have apparently been >> rejected by the kernel maintainers, so I'd hae to maintain my own >> fork of the kernel as well as port uprobes. I think. > > How close is your current kernel to fedora's? I've no idea. I'm currently using vanilla 2.6.30 sources with some AT91-specific patches from Atmel. >>> [...] User-space probing and kernel-space probing are basically >>> identical from the point of view of the stap user. >> >> Is the timing impact of a user-space probe no different than that of >> a kernel-space probe? > > It's very similar. > >>> [...] >>> The theoretical fit is pretty good. If in practice you are blocked >>> by some missing unported layer, you could decide between helping >>> port, prototyping on x86 while someone else ports, and/or >>> investigating other logging-related tools/libraries. >> >> I wouldn't mind working on porting uprobes if I was confident that it >> would be accepted upstream. Since utrace support was apparently not >> accepted, I'm not too optimistic. > > Another option is to go ahead and try to port uprobes, leave > ARM/utrace to us / fedora people. When/if the newer lkml-track > uprobes gets merged, the hypothetical ARM port could go into the main > kernel that way, bypassing the utrace kerfuffle. IOW, doing an ARM > port of the current systemtap-resident uprobes would not be a wasted > effort, if LKML gets its act together and merges the other one. OK, thanks. Can anybody provide a guess as to how much porting needs to done (assuming a competent kernel-mode programmer who knows nothing about the tracing stuff)? -- Grant Edwards grant.b.edwards Yow! Spreading peanut at butter reminds me of gmail.com opera!! I wonder why?