Re: user instruction tracing patch?

[Roland McGrath <roland at redhat dot com>]

> Yes, but the cases such as controlling many probes at once, or doing
> so indirectly (e.g., setting individual values of an alternation),
> makes the proposed syntax significantly more expressive, and IMO not
> really more opaque.

I see the point on expressivity for doing many probes.

> > or whatever syntax explicit enable/disable has?
> 
> There isn't an explicit syntax for that at all.  It's partly in desire
> to avoid having to invent it that we're implementing the conditional
> widget instead.

I understand that.  I'm talking about the expressivity and opacity of the
two options compared.  

I can't really agree that it's not substantially more opaque.  Perhaps if
there is a hard requirement on a special sort of variable name for it to be
an "active" one, but that again seems only very cosmetically different from
an explicit enabling syntax.  

What I find opaque in a way I don't like is the idea that I might need to
go through every probe and function body looking for things that might
modify "foo" to know when that means "trigger enabling/disabling itrace",
and then keep track of all such "foo"s by remembering the names used in all
the probe conditions I've read for all itrace (or similarly "active")
probes I've read.  If I were looking for "enable foo;" and "disable foo;"
or some other dedicated syntax, then I would feel much more comfortable
that I could understand what a large body of script code might be doing.
If it's "active:foo = ...", that's fine too, if I can be sure that looking
at all /\<active:.*/ occurrences is exhaustive.  

Basically, my opinion of the fiction that instruction tracing with a
condition is just like a rarely-hit probe with body { if (!condition) { ... }}
is that it's a double-edged sword that's at least as sharp on the back edge
as on the front.  I like the straightforward expressivity.  But I also like
my concise syntax to have unmistakably unambiguous semantics about what's
setting a script-level flag and what's enabling a special kind of continual
sampling with extremely high overhead. 


Thanks,
Roland