dtrace discuss - Oct 2006 - When and when don''t probe clauses record

I''ve noticed in the past that probe clauses don''t always
record into the
buffer.  I don''t see anything in the manual that specifically states 
this, but it appears that if a probe clause has statements (i.e. 
assignments), but no actions (recording or exit(), etc.) that the probe 
clause doesn''t even record the EPID.  Can anyone confirm this to be an 
accurate assessment?  Is there more to the rule of when a clause records 
and when it doesn''t, or is this pretty much it?

(Making sure my info is accurate for an article.)

Thanks,
Chip

Hi Chip,

Your understanding is indeed correct. If a clause contains actions
and none of them store any data then we don''t even record the EPID
into the principal buffer.

The DTrace user guide implicitly states this in the discussion at the
start of Chapter 10 on the "Default Action".

Cheers.

Jon.


Chip Bennett wrote On 10/21/06 20:10,:
> I''ve noticed in the past that probe clauses don''t always
record into
> the buffer.  I don''t see anything in the manual that specifically 
> states this, but it appears that if a probe clause has statements 
> (i.e. assignments), but no actions (recording or exit(), etc.) that 
> the probe clause doesn''t even record the EPID.  Can anyone confirm
> this to be an accurate assessment?  Is there more to the rule of when 
> a clause records and when it doesn''t, or is this pretty much it?
>
> (Making sure my info is accurate for an article.)
>
> Thanks,
> Chip
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Jonathan,

Well, this is what it says:

"A clause can contain any number of actions and variable manipulations. 
If a clause is
left empty, the default action is taken. The default action is to trace 
the enabled probe
identifier (EPID) to the principal buffer. The EPID identifies a 
particular enabling of a
particular probe with a particular predicate and actions. From the EPID, 
DTrace
consumers can determine the probe that induced the action. Indeed, 
whenever any
data is traced, it must be accompanied by the EPID to enable the 
consumer to make
sense of the data. Therefore, the default action is to trace the EPID 
and nothing else."

I''m not seeing: 1) no actions, record nothing, 2) non-recording
actions,
record default

But thanks for the confirmation.

At the same time, this makes sense.  If all you''re doing is making 
calculations (like future predicates, or aggregations), you probably 
don''t want to see that the probe fired.

Chip

Jonathan Haslam wrote:
> Hi Chip,
>
> Your understanding is indeed correct. If a clause contains actions
> and none of them store any data then we don''t even record the EPID
> into the principal buffer.
>
> The DTrace user guide implicitly states this in the discussion at the
> start of Chapter 10 on the "Default Action".
>
> Cheers.
>
> Jon.
>
>
> Chip Bennett wrote On 10/21/06 20:10,:
>
>> I''ve noticed in the past that probe clauses don''t
always record into
>> the buffer.  I don''t see anything in the manual that
specifically
>> states this, but it appears that if a probe clause has statements 
>> (i.e. assignments), but no actions (recording or exit(), etc.) that 
>> the probe clause doesn''t even record the EPID.  Can anyone
confirm
>> this to be an accurate assessment?  Is there more to the rule of when 
>> a clause records and when it doesn''t, or is this pretty much
it?
>>
>> (Making sure my info is accurate for an article.)
>>
>> Thanks,
>> Chip
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>

> I''m not seeing: 1) no actions, record nothing, 2) non-recording 
> actions, record default
I could be misunderstanding you here but just to clarify. What
you should be seeing here is this:

If a clause contains *any* actions (any statements) at all then
we do not take the default action but store just what is explicitly
recorded. Therefore:

fbt::clock:entry
{
    self->in = 1;
}

stores nothing into the principal buffer whereas:

fbt::clock:entry
{
}

will record the EPID. If you are seeing any different to this then
let us know.

Cheers.

Jon.
>
> But thanks for the confirmation.
>
> At the same time, this makes sense.  If all you''re doing is making
> calculations (like future predicates, or aggregations), you probably 
> don''t want to see that the probe fired.
>
> Chip
>
> Jonathan Haslam wrote:
>
>> Hi Chip,
>>
>> Your understanding is indeed correct. If a clause contains actions
>> and none of them store any data then we don''t even record the
EPID
>> into the principal buffer.
>>
>> The DTrace user guide implicitly states this in the discussion at the
>> start of Chapter 10 on the "Default Action".
>>
>> Cheers.
>>
>> Jon.
>>
>>
>> Chip Bennett wrote On 10/21/06 20:10,:
>>
>>> I''ve noticed in the past that probe clauses don''t
always record into
>>> the buffer.  I don''t see anything in the manual that
specifically
>>> states this, but it appears that if a probe clause has statements 
>>> (i.e. assignments), but no actions (recording or exit(), etc.) that
>>> the probe clause doesn''t even record the EPID.  Can anyone
confirm
>>> this to be an accurate assessment?  Is there more to the rule of 
>>> when a clause records and when it doesn''t, or is this
pretty much it?
>>>
>>> (Making sure my info is accurate for an article.)
>>>
>>> Thanks,
>>> Chip
>>> _______________________________________________
>>> dtrace-discuss mailing list
>>> dtrace-discuss at opensolaris.org
>>
>>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

What I''m seeing is:

fbt::clock:entry  { self->in = 1; }

generates no recording data, but:

fbt::clock:entry { self->in = 1; exit(0); }

generates the default data (EPID).  Any action (as define by the doc, 
which means an assignment statement is not an action) causes the default 
action to happen.

Chip

Jonathan Haslam wrote:
>
>> I''m not seeing: 1) no actions, record nothing, 2)
non-recording
>> actions, record default
>
> I could be misunderstanding you here but just to clarify. What
> you should be seeing here is this:
>
> If a clause contains *any* actions (any statements) at all then
> we do not take the default action but store just what is explicitly
> recorded. Therefore:
>
> fbt::clock:entry
> {
>    self->in = 1;
> }
>
> stores nothing into the principal buffer whereas:
>
> fbt::clock:entry
> {
> }
>
> will record the EPID. If you are seeing any different to this then
> let us know.
>
> Cheers.
>
> Jon.
>
>>
>> But thanks for the confirmation.
>>
>> At the same time, this makes sense.  If all you''re doing is
making
>> calculations (like future predicates, or aggregations), you probably 
>> don''t want to see that the probe fired.
>>
>> Chip
>>
>> Jonathan Haslam wrote:
>>
>>> Hi Chip,
>>>
>>> Your understanding is indeed correct. If a clause contains actions
>>> and none of them store any data then we don''t even record
the EPID
>>> into the principal buffer.
>>>
>>> The DTrace user guide implicitly states this in the discussion at
the
>>> start of Chapter 10 on the "Default Action".
>>>
>>> Cheers.
>>>
>>> Jon.
>>>
>>>
>>> Chip Bennett wrote On 10/21/06 20:10,:
>>>
>>>> I''ve noticed in the past that probe clauses
don''t always record
>>>> into the buffer.  I don''t see anything in the manual
that
>>>> specifically states this, but it appears that if a probe clause
has
>>>> statements (i.e. assignments), but no actions (recording or
exit(),
>>>> etc.) that the probe clause doesn''t even record the
EPID.  Can
>>>> anyone confirm this to be an accurate assessment?  Is there
more to
>>>> the rule of when a clause records and when it doesn''t,
or is this
>>>> pretty much it?
>>>>
>>>> (Making sure my info is accurate for an article.)
>>>>
>>>> Thanks,
>>>> Chip
>>>> _______________________________________________
>>>> dtrace-discuss mailing list
>>>> dtrace-discuss at opensolaris.org
>>>
>>>
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>

Chip Bennett wrote On 10/23/06 16:08,:
> What I''m seeing is:
>
> fbt::clock:entry  { self->in = 1; }
>
> generates no recording data, but:
>
> fbt::clock:entry { self->in = 1; exit(0); }
>
> generates the default data (EPID).  Any action (as define by the doc, 
> which means an assignment statement is not an action) causes the 
> default action to happen.
I think the user guide can appear to be slightly ambiguous
here as to the description of exactly what an action is. Chapter
4 ( D Program and Structure) may not appear, at first, to
tally with the description given in Chapter 10 (Actions and
Subroutines). However, a DIF expression is indeed an action. It
may not be a data recording action but it is an action (of type
DTRACEACT_DIFEXPR - see sys/dtrace.h). Maybe one of the
team will chime in here if they have any differing view.

Your second example above contains a data recording action, exit().
It has to store data because it needs to return the exit status.
The default action is to record the EPID and nothing else but
here we record the EPID and the exit status. It looks the same
as the default action because the consumer (dtrace(1M)) is spitting
out its usual headers of CPU, probeid and probefunc/probename and
there is no additional ouput generated by the exit() action.

Hope this helps.

Cheers.

Jon.
>
> Chip
>
> Jonathan Haslam wrote:
>
>>
>>> I''m not seeing: 1) no actions, record nothing, 2)
non-recording
>>> actions, record default
>>
>>
>> I could be misunderstanding you here but just to clarify. What
>> you should be seeing here is this:
>>
>> If a clause contains *any* actions (any statements) at all then
>> we do not take the default action but store just what is explicitly
>> recorded. Therefore:
>>
>> fbt::clock:entry
>> {
>>    self->in = 1;
>> }
>>
>> stores nothing into the principal buffer whereas:
>>
>> fbt::clock:entry
>> {
>> }
>>
>> will record the EPID. If you are seeing any different to this then
>> let us know.
>>
>> Cheers.
>>
>> Jon.
>>
>>>
>>> But thanks for the confirmation.
>>>
>>> At the same time, this makes sense.  If all you''re doing
is making
>>> calculations (like future predicates, or aggregations), you
probably
>>> don''t want to see that the probe fired.
>>>
>>> Chip
>>>
>>> Jonathan Haslam wrote:
>>>
>>>> Hi Chip,
>>>>
>>>> Your understanding is indeed correct. If a clause contains
actions
>>>> and none of them store any data then we don''t even
record the EPID
>>>> into the principal buffer.
>>>>
>>>> The DTrace user guide implicitly states this in the discussion
at the
>>>> start of Chapter 10 on the "Default Action".
>>>>
>>>> Cheers.
>>>>
>>>> Jon.
>>>>
>>>>
>>>> Chip Bennett wrote On 10/21/06 20:10,:
>>>>
>>>>> I''ve noticed in the past that probe clauses
don''t always record
>>>>> into the buffer.  I don''t see anything in the
manual that
>>>>> specifically states this, but it appears that if a probe
clause
>>>>> has statements (i.e. assignments), but no actions
(recording or
>>>>> exit(), etc.) that the probe clause doesn''t even
record the EPID.
>>>>> Can anyone confirm this to be an accurate assessment?  Is
there
>>>>> more to the rule of when a clause records and when it
doesn''t, or
>>>>> is this pretty much it?
>>>>>
>>>>> (Making sure my info is accurate for an article.)
>>>>>
>>>>> Thanks,
>>>>> Chip
>>>>> _______________________________________________
>>>>> dtrace-discuss mailing list
>>>>> dtrace-discuss at opensolaris.org
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> dtrace-discuss mailing list
>>> dtrace-discuss at opensolaris.org
>>
>>
>

Jonathan Haslam wrote:
>
> Your second example above contains a data recording action, exit().
> It has to store data because it needs to return the exit status.
> The default action is to record the EPID and nothing else but
> here we record the EPID and the exit status. It looks the same
> as the default action because the consumer (dtrace(1M)) is spitting
> out its usual headers of CPU, probeid and probefunc/probename and
> there is no additional ouput generated by the exit() action.
>
Since exit() wasn''t with the rest of the recording actions, I assumed
it
wasn''t till I read it more closely, where it say that technically, it 
_is_ a recording action.  So I tried a destructive action, raise(), and 
sure enough, it did not cause anything to be recorded.

So I get it now.  Empty clause -> default recording action; anything in 
the clause -> record only what the recording actions say to record.

Thanks,
Chip