From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10290 invoked by alias); 1 May 2006 17:53:26 -0000 Received: (qmail 10283 invoked by uid 22791); 1 May 2006 17:53:25 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga01.intel.com (HELO fmsmga101-1.fm.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 01 May 2006 17:53:23 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 01 May 2006 10:53:21 -0700 Received: from scsmsx331.sc.intel.com (HELO scsmsx331.amr.corp.intel.com) ([10.3.90.4]) by fmsmga001.fm.intel.com with ESMTP; 01 May 2006 10:53:21 -0700 X-IronPort-AV: i="4.04,169,1144047600"; d="scan'208"; a="30851557:sNHT46260536" Received: from scsmsx403.amr.corp.intel.com ([10.3.90.18]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 10:53:21 -0700 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: Tapset difficulties w/ functions Date: Mon, 01 May 2006 17:53:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tapset difficulties w/ functions thread-index: AcZskWAeHUURrFtsQJKw/hWxqrktvQAsOdnQ From: "Stone, Joshua I" To: Cc: X-OriginalArrivalTime: 01 May 2006 17:53:21.0374 (UTC) FILETIME=[22B10FE0:01C66D48] X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00286.txt.bz2 On Sunday, April 30, 2006 1:05 PM, fche@redhat.com wrote: > Would this "fault-tolerant" wildcarding have an advantage over an > explicit "optional probe" syntax like this: >=20 > probe FOO ? { } > probe alias =3D BAR ?, BAZ ? { } >=20 > Then the first alternative would be expressed thusly, if they can > share handlers: >=20 > probe process.exec =3D kernel.function("do_execve") ?, > kernel.function("compat_do_execve") ? > { /* do stuff */ } Actually, I like this explicitly-optional syntax better -- it would let me specify in this case that do_execve is required but compat_do_execve is optional. In this way it is better than the "soft" wildcards. One strong point of the wildcard is that it does ensure that there's at least one match. The "optional" flag can be made to do this even better if we're careful how it's implemented. Looking at your example, if FOO isn't found then that probe can be discarded. For your alias example, I think it should work two ways if both BAR and BAZ are not found: probe alias {} // error, probepoint not found probe alias ? {} // ok, probe is discarded Similarly, if a syscall "sys_foobar" isn't found: tapset: probe syscall.foobar =3D kernel.function("sys_foobar") ? {} user script: probe syscall.* {} // ok if other syscalls were found probe syscall.foobar {} // error, probepoint not found probe syscall.foobar ? {} // ok, probe is discarded It still would be nice to have some syntactic sugar for function-or-inline and kernel-or-module, lest we end up with tapsets littered like so: probe xyzzy.foo =3D kernel.function("xyzzy_foo") ?, kernel.inline("xyzzy_foo") ?, module("xyzzy").function("xyzzy_foo") ?, module("xyzzy").inline("xyzzy_foo") ? { /* do stuff */ } Perhaps instead: probe xyzzy.foo =3D softmodule("xyzzy").softfunction("xyzzy_foo") { /* do stuff */ } Josh