[Bug translator/4935] New: support on-the-fly probe enable/disable syntax

[Bug translator/4935] New: support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

See http://sourceware.org/ml/systemtap/2007-q3/msg00023.html for
one possibility.

-- 
           Summary: support on-the-fly probe enable/disable syntax
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |3859
              nThis|                            |


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-10-08 16:49 -------
I'm interested in this feature.

As far as I understand, with this feature, systemtap treats the next script ;
---
 probe ALIAS=PROBEPOINT { stmt1; }
 probe ALIAS if (expr) { stmt2; }
---
as
---
 probe PROBEPOINT { if (!expr) next; stmt1; stmt2}
---

In that case, 
---
 probe ALIAS=PROBEPOINT { stmt1; }
 probe ALIAS if (expr) { stmt2; }
 probe ALIAS { stmt3; }
---
will be treated as
---
 probe PROBEPOINT { if (!expr) next; stmt1; stmt2}
 probe PROBEPOINT { stmt1; stmt3}
---
Is that right?


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-10-08 17:10 -------
> In that case, 
> ---
>  probe ALIAS=PROBEPOINT { stmt1; }
>  probe ALIAS if (expr) { stmt2; }
>  probe ALIAS { stmt3; }
> ---
> will be treated as
> ---
>  probe PROBEPOINT { if (!expr) next; stmt1; stmt2}
>  probe PROBEPOINT { stmt1; stmt3}
> ---
> Is that right?

That's right.  It wouldn't make sense to act as if the conditional
was within the probe handler block (after the prefix from aliases),
since that would require the underlying probe to still be active.

It also means that the variables in "expr" can in practice only involve
global script-level variables.  (Even pure embedded-C functions can
change their values frequently enough to make them impractical as
part of an automatic predicate.  In this sort of case, we could opt
to automatically translate the script to the "{ if (!expr) next; ... }"
form, which would run correctly but slowly.)


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-11-16 23:40 -------
Created an attachment (id=2095)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2095&action=view)
on-the-fly enable/disable probes patch for parser and elabolator

I developed a patch for the parser and the elabolator to support this syntax.

Currently, this just translates the next script;
---
 probe ALIAS=PROBEPOINT if (expr1) { stmt1 }
 probe ALIAS if (expr2) { stmt2 }
---
to below;
---
 probe PROBEPOINT { 
   if (!((expr2)&&(expr1))) next
   stmt1
   stmt2
 }
---

This patch adds "if (..)" condition to the PROBEPOINT instead of "probe".
So, you can write the below script with this patch;
---
 probe PP1 if (expr1), PP2 if (expr2) {stmt}
---
This is translated to below;
---
 probe PP1 { 
   if (!expr1) next 
   stmt
 }
 probe PP2 {
   if (!expr2) next
   stmt
 }
---

This is the first step of this feature, since this patch does not
include optimization code.

Thanks,


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [Bug translator/4935] support on-the-fly probe enable/disable syntax

[Frank Ch. Eigler]

Hi -

> I developed a patch for the parser and the elabolator to support
> this syntax.  Currently, this just translates the next script; [...]
> This is the first step of this feature, since this patch does not
> include optimization code.

It is a fine start.  Please merge & commit it.  Are you planning to
write some tests & documentation for this new syntax?

The optimization wor (automagic probe disable/enable operations) will
be much bigger, and we should share the work.

- FChE

Re: [Bug translator/4935] support on-the-fly probe enable/disable syntax

[Masami Hiramatsu]

Hi,

Frank Ch. Eigler wrote:
> Hi -
> 
>> I developed a patch for the parser and the elabolator to support
>> this syntax.  Currently, this just translates the next script; [...]
>> This is the first step of this feature, since this patch does not
>> include optimization code.
> 
> It is a fine start.  Please merge & commit it.  Are you planning to
> write some tests & documentation for this new syntax?

Thanks, I'm writing some tests for this syntax and updating a manual.
I think the most part of documents might be fixed after the optimization
is implemented.

> The optimization wor (automagic probe disable/enable operations) will
> be much bigger, and we should share the work.

Indeed. The arm/disarm-probe methods for each kind of probes are
different. So I think we'd better implement it one by one.

> 
> - FChE


-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com, masami.hiramatsu.pt@hitachi.com

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-11-27 16:02 -------
Created an attachment (id=2110)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2110&action=view)
A bugfix patch for on-the-fly probe enable/disable syntax

This patch fixes a bug in the previous patch to allow user to access kernel
variables in the condition expression of probe points.


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-11-27 16:15 -------
(In reply to comment #4)
> This patch fixes a bug in the previous patch to allow user to access kernel
> variables in the condition expression of probe points.

Please note that use of this capability would render the probe un-disableable,
since kernel $context variables need to be evaluated from a single particular
kprobe rather than anywhere in the script.


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-11-27 23:10 -------
(In reply to comment #5)
> Please note that use of this capability would render the probe un-disableable,
> since kernel $context variables need to be evaluated from a single particular
> kprobe rather than anywhere in the script.
> 

Sure, I agree.
I think when we access only global variables in the condition and those 
variables are not changed in the probe point, the probe will be disabled
automagically from other probes where those global variables are changed.
And This optimization depends on where the global variables are changed.
Procfs probes and timer probe are good places to do that.


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-12-04 20:45 -------
Created an attachment (id=2122)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2122&action=view)
Documentation patch for on-the-fly probe enable/disable syntax

This patch adds comments in manpage and NEWS.

-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-12-04 20:47 -------
Created an attachment (id=2123)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2123&action=view)
Testcases for on-the-fly probe enable/disable syntax

This patch adds testcases for on-the-fly probe enable/disable syntax, which
includes:
- parser tests (ok/ko)
- semantic tests (ok/ko)
- basic functionality test


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-12-05 17:08 -------
Thank you, these are good to commit.
We can fix minor spelling errors in CVS.
One question regarding the new semko/thirtynine test: why should that fail
rather than be interpreted as an unconditional probe that happens to contain
".if(1)" as the last probe point component?


-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2007-12-05 19:21 -------
(In reply to comment #9)
> One question regarding the new semko/thirtynine test: why should that fail
> rather than be interpreted as an unconditional probe that happens to contain
> ".if(1)" as the last probe point component?

Because the "if()" statement is not a component of a probe point, you should NOT
 use it with ".".

The parser passes ".if(1)" as a probe point component.However, the elaborator
fails to resolve it, so it is "semko".

Here is the error output:
---
semantic error: probe point mismatch at position 2 (alternatives: call inline
return) while resolving probe point kernel.function("sys_open").if(1)
---

Thanks,

-- 


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |fche at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[mhiramat at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |6933


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/4935] support on-the-fly probe enable/disable syntax

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |10995
              nThis|                            |


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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.