From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18529 invoked by alias); 18 Jan 2007 19:55:27 -0000 Received: (qmail 17820 invoked by uid 48); 18 Jan 2007 19:55:14 -0000 Date: Thu, 18 Jan 2007 19:55:00 -0000 From: "joshua dot i dot stone at intel dot com" To: systemtap@sources.redhat.com Message-ID: <20070118195513.3887.joshua.i.stone@intel.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/3887] New: Need a syntax to specify probes alternatives X-Bugzilla-Reason: AssignedTo 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: 2007-q1/txt/msg00143.txt.bz2 This enhancement idea is a close cousin to bug #2645. I would like to have a way to list several alternatives for a probe point, and have the translator pick exactly one for implementation. With this, one could specify a preferred probe point, with an alternate probe point if the first is not available. My syntax suggestion is to use the boolean-OR ('||') operator when defining a probepoint, and the translator will resolve in the typical left-to-right, short-circuit fashion. For example, given 'probe kernel.function("foo") || kernel.function("bar") {}', the translator will resolve as follows: probeable: | probe foo | bar | used ------------------- Y | Y | foo Y | N | foo N | Y | bar N | N | *error* This sort of feature will be useful for defining portable tapsets and scripts. Some example usage ideas: probe scheduler.context_switch = kernel.mark("context_switch") || kernel.function("__switch_to") || kernel.inline("context_switch") {} If markers are available, use that. Otherwise, try __switch_to, which has good parameter information. Finally, try context_switch, but parameters might not work in inlines. Note that on some kernels all three might be ok, but only *one* is used. probe scsi.ioentry = kernel.function("scsi_prep_fn") || module("scsi_mod").function("scsi_prep_fn") {} This explicitly declares how to search for the function "scsi_prep_fn". The same can almost be achieved using the '?' operator on both alternatives, except that this new methods *requires* that one resolves correctly. (Consider the use of "scsi.*" -- if using '?' the ioentry might silently disappear on failure.) probe event.foobar = kernel.function("foobar") || foo_and_bar {} probe foo_and_bar = kernel.function("foo"), kernel.function("bar") {} This demonstrates how to achieve grouping. The translator will generate a single probe on "foobar" if it exists, or else it will use two probes on "foo" and "bar". We'll have to consider operator precedence and semantics. For example, what should happen in the following cases? 1. probe foobar = foo ? || bar {} 2. probe foobar = foo || bar ? {} -- Summary: Need a syntax to specify probes alternatives Product: systemtap Version: unspecified Status: NEW Severity: enhancement Priority: P2 Component: translator AssignedTo: systemtap at sources dot redhat dot com ReportedBy: joshua dot i dot stone at intel dot com http://sourceware.org/bugzilla/show_bug.cgi?id=3887 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.