[Bug tapsets/13450] New: get rid of most/all probe-alias "?" (optional) markup

[Bug tapsets/13450] New: get rid of most/all probe-alias "?" (optional) markup

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13450

             Bug #: 13450
           Summary: get rid of most/all probe-alias "?" (optional) markup
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap@sourceware.org
        ReportedBy: fche@redhat.com
    Classification: Unclassified


Probe aliases defined thusly:

    probe foo = bar?
      { }

does not do a lot for a script user.  It quietly fails when the
underlying bar probe point is not present.  If the end-user script
wishes to allow this, it should be written with the optional markup
of its own:

    probe foo ?  
      { }

We should review the tapset and generally get rid of as many of 
these optional markers (conditional on %( version %) ) as possible.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13450] get rid of most/all probe-alias "?" (optional) markup

[jistone at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13450

Josh Stone <jistone at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com

--- Comment #1 from Josh Stone <jistone at redhat dot com> 2011-11-29 17:18:48 UTC ---
(In reply to comment #0)
> It quietly fails when the underlying bar probe point is not present.

That's not true:

$ stap -e 'probe foo = bar ? {}  probe foo {}' -p2
semantic error: no match while resolving probe point foo
Pass 2: analysis failed.  Try again with another '--vp 01' option.

The optional tag on the alias allows a user to possibly match the probe with a
wildcard, but carry on if it doesn't resolve.

$ stap -e 'probe bar = foo ? {}  probe b* {}' -p2 -u
# probes
begin /* <- b* */

vs. 

$ stap -e 'probe bar = foo {}  probe b* {}' -p2 -u
semantic error: probe point mismatch at position 0  (alternatives: __nfs
__scheduler __signal __tcpmib __vm _linuxmib _signal _sunrpc _syscall _vfs bar
begin begin(number) end end(number) error error(number) generic ioblock
ioblock_trace ioscheduler ioscheduler_trace ipmib irq_handler kernel kprobe
kprocess linuxmib module(string) nd_syscall netdev never nfs nfsd perf process
process(number) process(string) procfs procfs(string) scheduler scsi signal
socket softirq stap staprun sunrpc syscall tcp tcpmib timer tty udp vfs vm
workqueue): identifier 'foo' at <input>:1:13 while resolving probe point foo
        source: probe bar = foo {}  probe b* {}
                            ^
Pass 2: analysis failed.  Try again with another '--vp 01' option.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug tapsets/13450] get rid of most/all probe-alias "?" (optional) markup

[fche at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13450

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> 2013-05-15 14:52:36 UTC ---
This is not clearly worthwhile.
OTOH, bug #14297 comment #3 worries rightly about our overmarking
of wildcard-processed/synthetic probes with 'optional' flags.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.