dtrace discuss - Jul 2006 - Definition of "anchored" and "unanchored" probes

Referring to the DTrace manual:

    "Module If this probe corresponds to a specific program location, 
the name of the module in which the probe is located. This name is 
either the name of a kernel module or the name of a user library.
    Function If this probe corresponds to a specific program location, 
the name of the program function in which the probe is located."

and then ...

"A probe that has a module and function as part of its name is known as 
an anchored probe, and one that does not is known as unanchored."

Here''s my question:  By the above definition, "pid" and
"fbt" or clearly
anchored providers since their probes specify specific locations in a 
program.  However, other providers, like "vminfo" or "proc",
while they
obviously fire at a specific location, are not really defined by that 
location, but rather by when a certain kind of event occurs.  And then 
there''s "sysproc" which is probably closer to being more like
"fbt", in
the way the user perceives it, than any of the others, but doesn''t have
a module, so by the above definition would be unanchored.

I understand why some providers have modules and some don''t (or at
least
I think I do):  I''m just looking for clarity on the definition of 
anchored and unanchored, so I can explain to others.

Thanks,
Chip

Chip,

I believe the Glossary item "probe" says it the clearest
  "....  A probe may be anchored to a particular module and function
or it may be unanchored if it is not associated with a particular
program location (e.g. profile timer)."
>From the above definition, ''fbt'', ''proc''
and ''vminfo'' probes are
definitely anchored.

''syscall'' probes are a little tricky since they are
implemented at the
gate into the respective OS functions.  The code path for enabled
''syscall'' probes goes through dtrace_systrace_syscall(32).  In
that
sense, I suspect that ''syscall'' probes are unanchored but I am
really
not sure.


-- 
Just me,
Wire ...

On 7/11/06, Chip Bennett <cbennett at laurustech.com>
wrote:
> Referring to the DTrace manual:
>
>     "Module If this probe corresponds to a specific program location,
> the name of the module in which the probe is located. This name is
> either the name of a kernel module or the name of a user library.
>     Function If this probe corresponds to a specific program location,
> the name of the program function in which the probe is located."
>
> and then ...
>
> "A probe that has a module and function as part of its name is known
as
> an anchored probe, and one that does not is known as unanchored."
>
> Here''s my question:  By the above definition, "pid" and
"fbt" or clearly
> anchored providers since their probes specify specific locations in a
> program.  However, other providers, like "vminfo" or
"proc", while they
> obviously fire at a specific location, are not really defined by that
> location, but rather by when a certain kind of event occurs.  And then
> there''s "sysproc" which is probably closer to being more
like "fbt", in
> the way the user perceives it, than any of the others, but doesn''t
have
> a module, so by the above definition would be unanchored.
>
> I understand why some providers have modules and some don''t (or at
least
> I think I do):  I''m just looking for clarity on the definition of
> anchored and unanchored, so I can explain to others.

Wee Yeh Tan writes:
 > Chip,
 > 
 > I believe the Glossary item "probe" says it the clearest
 >   "....  A probe may be anchored to a particular module and function
 > or it may be unanchored if it is not associated with a particular
 > program location (e.g. profile timer)."
 > 
 > >From the above definition, ''fbt'',
''proc'' and ''vminfo'' probes are
 > definitely anchored.
 > 
 > ''syscall'' probes are a little tricky since they are
implemented at the
 > gate into the respective OS functions.  The code path for enabled
 > ''syscall'' probes goes through
dtrace_systrace_syscall(32).  In that
 > sense, I suspect that ''syscall'' probes are unanchored
but I am really
 > not sure.
 > 

This  possibly  refers to  wether   or  not the  D  variable
probefunc   and probemod are    meaningful  or not in  probe
context.  With  syscall   provider  probefunc is,   but  not
probemod; maybe    that   makes syscalls   probes  partially
anchored ?

-r

 > 
 > -- 
 > Just me,
 > Wire ...
 > 
 > On 7/11/06, Chip Bennett <cbennett at laurustech.com> wrote:
 > > Referring to the DTrace manual:
 > >
 > >     "Module If this probe corresponds to a specific program
location,
 > > the name of the module in which the probe is located. This name is
 > > either the name of a kernel module or the name of a user library.
 > >     Function If this probe corresponds to a specific program
location,
 > > the name of the program function in which the probe is located."
 > >
 > > and then ...
 > >
 > > "A probe that has a module and function as part of its name is
known as
 > > an anchored probe, and one that does not is known as
unanchored."
 > >
 > > Here''s my question:  By the above definition,
"pid" and "fbt" or clearly
 > > anchored providers since their probes specify specific locations in a
 > > program.  However, other providers, like "vminfo" or
"proc", while they
 > > obviously fire at a specific location, are not really defined by that
 > > location, but rather by when a certain kind of event occurs.  And
then
 > > there''s "sysproc" which is probably closer to
being more like "fbt", in
 > > the way the user perceives it, than any of the others, but
doesn''t have
 > > a module, so by the above definition would be unanchored.
 > >
 > > I understand why some providers have modules and some don''t
(or at least
 > > I think I do):  I''m just looking for clarity on the
definition of
 > > anchored and unanchored, so I can explain to others.
 > _______________________________________________
 > dtrace-discuss mailing list
 > dtrace-discuss at opensolaris.org

These are good thoughts, and maybe I''m "picking nits": its
just didn''t
seem clear cut to me.

Perhaps we could round this discussion out with a thought from one of 
the authors of the manual?

Thanks,
Chip

Roch wrote:
>
>Wee Yeh Tan writes:
> > Chip,
> > 
> > I believe the Glossary item "probe" says it the clearest
> >   "....  A probe may be anchored to a particular module and
function
> > or it may be unanchored if it is not associated with a particular
> > program location (e.g. profile timer)."
> > 
> > >From the above definition, ''fbt'',
''proc'' and ''vminfo'' probes are
> > definitely anchored.
> > 
> > ''syscall'' probes are a little tricky since they are
implemented at the
> > gate into the respective OS functions.  The code path for enabled
> > ''syscall'' probes goes through
dtrace_systrace_syscall(32).  In that
> > sense, I suspect that ''syscall'' probes are
unanchored but I am really
> > not sure.
> > 
>
>This  possibly  refers to  wether   or  not the  D  variable
>probefunc   and probemod are    meaningful  or not in  probe
>context.  With  syscall   provider  probefunc is,   but  not
>probemod; maybe    that   makes syscalls   probes  partially
>anchored ?
>
>-r
>
> > 
> > -- 
> > Just me,
> > Wire ...
> > 
> > On 7/11/06, Chip Bennett <cbennett at laurustech.com> wrote:
> > > Referring to the DTrace manual:
> > >
> > >     "Module If this probe corresponds to a specific program
location,
> > > the name of the module in which the probe is located. This name
is
> > > either the name of a kernel module or the name of a user library.
> > >     Function If this probe corresponds to a specific program
location,
> > > the name of the program function in which the probe is
located."
> > >
> > > and then ...
> > >
> > > "A probe that has a module and function as part of its name
is known as
> > > an anchored probe, and one that does not is known as
unanchored."
> > >
> > > Here''s my question:  By the above definition,
"pid" and "fbt" or clearly
> > > anchored providers since their probes specify specific locations
in a
> > > program.  However, other providers, like "vminfo" or
"proc", while they
> > > obviously fire at a specific location, are not really defined by
that
> > > location, but rather by when a certain kind of event occurs.  And
then
> > > there''s "sysproc" which is probably closer to
being more like "fbt", in
> > > the way the user perceives it, than any of the others, but
doesn''t have
> > > a module, so by the above definition would be unanchored.
> > >
> > > I understand why some providers have modules and some
don''t (or at least
> > > I think I do):  I''m just looking for clarity on the
definition of
> > > anchored and unanchored, so I can explain to others.
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
>
>  
>

On Tue, Jul 11, 2006 at 09:48:37AM -0500, Chip Bennett
wrote:
> These are good thoughts, and maybe I''m "picking nits":
its just didn''t
> seem clear cut to me.
> 
> Perhaps we could round this discussion out with a thought from one of 
> the authors of the manual?
An anchored probe is one that is associated with the synchronous execution
of a particular instruction; an unanchored probe is asynchronous with
respect to the instruction stream.  The syscall, FBT, SDT, USDT and pid
providers are all anchored; the profile provider is unanchored -- as
would be (for example) a provider based on CPU performance counter
overflow, should that be developed.

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

Bryan,

Thanks for clarifying.  So this makes vminfo and proc anchored, right?

But doesn''t this also sort of make BEGIN and END anchored?  Granted, 
they would be degenerate cases, but synchronous to the execution of a 
particular instruction, nonetheless.  Or should I just say that because 
the dtrace provider''s probes fire outside the boundaries of normal 
program execution, they''re an exception? (Again, in order to teach 
others, I''m just trying to get a good handle on the meaning.)

Thanks,
Chip

Bryan Cantrill wrote:
>On Tue, Jul 11, 2006 at 09:48:37AM -0500, Chip Bennett wrote:
>  
>
>>These are good thoughts, and maybe I''m "picking
nits": its just didn''t
>>seem clear cut to me.
>>
>>Perhaps we could round this discussion out with a thought from one of 
>>the authors of the manual?
>>    
>>
>
>An anchored probe is one that is associated with the synchronous execution
>of a particular instruction; an unanchored probe is asynchronous with
>respect to the instruction stream.  The syscall, FBT, SDT, USDT and pid
>providers are all anchored; the profile provider is unanchored -- as
>would be (for example) a provider based on CPU performance counter
>overflow, should that be developed.
>
>	- Bryan
>
>--------------------------------------------------------------------------
>Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc
>  
>