This is a semantic question. (I''m doing some technical writing about
DTrace.)
I''ll little confused about how to explain what an "action"
is. By any
definition, "trace(x);" is an action. However, what about just
"i++;"?
Looking at the DTrace guide page 76:
"Probe actions are described by a list of statements separated by
semicolons (;) and enclosed in braces { }."
However, at the beginning of chapter 10 (page 127)
"Actions enable your DTrace programs to interact with the system outside
of DTrace. The most common actions record data to a DTrace buffer.
Other actions are available, such as stopping the current process,
raising a specific signal on the current process, or ceasing tracing
altogether. Some of these actions are destructive in that they change
the system, albeit in a well-defined way. These actions may only be used
if destructive actions have been explicitly enabled."
To me, the first reference would imply that "i++;" is an action, but
the
second reference implies it isn''t. And if actions are just the
specific
statement discussed in chapter 10, then what is everything else inside
the braces that isn''t an action or a subroutine?
Thanks,
Chip
On Mon, Jul 24, 2006 at 12:01:32PM -0500, Chip Bennett wrote:> This is a semantic question. (I''m doing some technical writing about > DTrace.) > > I''ll little confused about how to explain what an "action" is. By any > definition, "trace(x);" is an action. However, what about just "i++;"? > Looking at the DTrace guide page 76: > > "Probe actions are described by a list of statements separated by > semicolons (;) and enclosed in braces { }." > > However, at the beginning of chapter 10 (page 127) > > "Actions enable your DTrace programs to interact with the system outside > of DTrace. The most common actions record data to a DTrace buffer. > Other actions are available, such as stopping the current process, > raising a specific signal on the current process, or ceasing tracing > altogether. Some of these actions are destructive in that they change > the system, albeit in a well-defined way. These actions may only be used > if destructive actions have been explicitly enabled." > > To me, the first reference would imply that "i++;" is an action, but the > second reference implies it isn''t.In general, it''s best to think of actions as the first sentence of the second paragraph describes them -- as interacting with the system outside of DTrace. Technically, the first definition is correct, but it''s not quite complete: statements that don''t affect the system outside of DTrace are lumped into a single action (DTRACEACT_DIFEXPR) that are interpreted as a data-recording action (into the principal buffer) with a size of 0. But this is really an implementation detail; the essential bit here is that actions are different from subroutines because they cannot be assigned to an lvalue. That is, you cannot use an action in an expression. This can be annoying: stack()/ustack()/jstack(), mod()/umod(), and sym()/usym() (among others) are all actions that one might like to have be subroutines -- in particular to be able to use them in predicates. But the reality is that each of these requires some amount of postprocessing, forcing them to be actions (which can be postprocessed) instead of subroutines (which are all processed in situ in the DIF emulation engine in the kernel). Does that help? - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
Bryan Cantrill wrote:>On Mon, Jul 24, 2006 at 12:01:32PM -0500, Chip Bennett wrote: > > >>This is a semantic question. (I''m doing some technical writing about >>DTrace.) >> >>I''ll little confused about how to explain what an "action" is. By any >>definition, "trace(x);" is an action. However, what about just "i++;"? >>Looking at the DTrace guide page 76: >> >>"Probe actions are described by a list of statements separated by >>semicolons (;) and enclosed in braces { }." >> >>However, at the beginning of chapter 10 (page 127) >> >>"Actions enable your DTrace programs to interact with the system outside >>of DTrace. The most common actions record data to a DTrace buffer. >>Other actions are available, such as stopping the current process, >>raising a specific signal on the current process, or ceasing tracing >>altogether. Some of these actions are destructive in that they change >>the system, albeit in a well-defined way. These actions may only be used >>if destructive actions have been explicitly enabled." >> >>To me, the first reference would imply that "i++;" is an action, but the >>second reference implies it isn''t. >> >> > >In general, it''s best to think of actions as the first sentence of the >second paragraph describes them -- as interacting with the system outside >of DTrace. Technically, the first definition is correct, but it''s not >quite complete: statements that don''t affect the system outside of >DTrace are lumped into a single action (DTRACEACT_DIFEXPR) that are >interpreted as a data-recording action (into the principal buffer) with a >size of 0. > >But this is really an implementation detail; the essential bit here is that >actions are different from subroutines because they cannot be assigned to >an lvalue. That is, you cannot use an action in an expression. This can >be annoying: stack()/ustack()/jstack(), mod()/umod(), and sym()/usym() >(among others) are all actions that one might like to have be subroutines -- >in particular to be able to use them in predicates. But the reality is that >each of these requires some amount of postprocessing, forcing them to >be actions (which can be postprocessed) instead of subroutines (which are >all processed in situ in the DIF emulation engine in the kernel). > >Does that help? > >This makes sense. Now, I''ve just got to figure out how I''m going to say it without going into too much detail that is beyond the scope of the article. Thanks, Chip