From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23255 invoked by alias); 13 Dec 2006 23:17:55 -0000 Received: (qmail 23245 invoked by uid 22791); 13 Dec 2006 23:17:53 -0000 X-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50 X-Spam-Check-By: sourceware.org Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Dec 2006 23:17:32 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 13 Dec 2006 15:17:29 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 13 Dec 2006 15:17:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,164,1165219200"; d="scan'208"; a="174164850:sNHT3330140940" Received: from scsmsx412.amr.corp.intel.com ([10.3.90.31]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 15:17:21 -0800 Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx412.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 15:17:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: is systemtap's language more complicated than needed. Date: Thu, 14 Dec 2006 00:46:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is systemtap's language more complicated than needed. Thread-Index: Acce/6QlesZVAGXpTgukluwf+TqmQAABmtyQ From: "Stone, Joshua I" To: "James Dickens" Cc: "SystemTAP" X-OriginalArrivalTime: 13 Dec 2006 23:17:21.0251 (UTC) FILETIME=[D71E6330:01C71F0C] 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: 2006-q4/txt/msg00666.txt.bz2 On Wednesday, December 13, 2006 1:35 PM, James Dickens wrote: > seems to be over kill, as an end user it would be easier if there was > just one kernel probe type and let systemtap's parser figure out what > exactly is needed to probe the right points. [...] >=20 > kernel("functionname") /* either a function or inlined, parser must > figure it out */ > kernel("functionname[file]") /* either a function or inlined, parser > must figure it out */ > kernel("kernel/sched.c:2917") /* a line in a file */ (Statement probes can also be raw addresses, but this kind of thing would still work.) I think what you're suggesting has some merit, and is also supported by precedence in most debuggers -- i.e., to set a breakpoint you just state the location, and the debugger resolves it as necessary. I don't think it's THAT painful to have to say kernel, inline, or statement, but I see where you're coming from. One reason that we distinguish between function and inline is because we can't put return probes on inlines. I think this is the original motivation for the split. There also the need to have some understanding of what placing a probe entails. With a function probe, you get one probe point, always in the module where it's defined. With an inline, it will likely resolve to many points, perhaps not limited to any one module. A function like get_current(), while defined in the base kernel, will be instanced in thousands of places across all modules. It's a little reckless to do that sort of expansion behind the user's back. It gets really hairy when you account for wildcards. You've significantly widened the scope if probing kernel("*") means probing all functions AND all instances of inline functions. With that said... > this change will make it much easier to read and create scripts for > the end user, especially if a function is inlined at some point in the > future. This is a strong point in your favor, for the maintainability of scripts and tapsets. And given that the compiler might also inline functions on its own, the function/inline distinction can be a real headache. Perhaps we could implement what you suggest as a shorthand, but still leave the function/inline/statement variants in place to allow one to be explicit. Anyone else have thoughts? Josh