From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29447 invoked by alias); 14 May 2006 20:24:09 -0000 Received: (qmail 10591 invoked by uid 48); 14 May 2006 20:22:58 -0000 Date: Sun, 14 May 2006 20:24:00 -0000 Message-ID: <20060514202258.10586.qmail@sourceware.org> From: "joshua dot i dot stone at intel dot com" To: systemtap@sources.redhat.com In-Reply-To: <20060508205847.2645.joshua.i.stone@intel.com> References: <20060508205847.2645.joshua.i.stone@intel.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/2645] Need a syntax to specify optional probes X-Bugzilla-Reason: AssignedTo 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/msg00402.txt.bz2 ------- Additional Comments From joshua dot i dot stone at intel dot com 2006-05-14 20:22 ------- (In reply to comment #3) > If I understand the concern correctly, in this scenario, > probe group.f = pp ? { } # in tapset > probe group.* { } # in user script > and for missing "pp", should this succeed or fail? There is an ambiguity. > With the current flavouring of the code, it would fail, since the group.* > match would expand to an empty set of derived_probe's. I think failure is correct here. With missing "pp", "group.*" should fail, yet "group.* ?" would be ok. If there were another alias, "probe group.g = qq ? {}", then "group.*" will succeed iff at least one of "pp" and "qq" are found. > With a little bit of extra work, we can let the tapset author make this pass. > Let's provide a new probe point "never", which would be similar to "begin" > and "end" but never actually run its handler. (It doesn't even need to show > up in the translated C code.) Then, if a tapset author wants to make the > alias succeed with a missing pp, even for non-optional users, he can say: > probe group.f = pp ? , never { } # in tapset I think this is a good workaround if a tapset author really wants to write a probe that could possibly do nothing. While I personally think this should be discouraged, for the reasons I gave in comment #2, it may be good to allow this possibility to cover all use cases. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2645 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.