dtrace discuss - Aug 2006 - How to know SDT probe''s "argument numbers" & "argument types"?

Hi gurus,

Is there any easy way to know how many arguments a SDT probe has?   e.g.

# dtrace -lvn callout-start
   ID   PROVIDER            MODULE                          FUNCTION NAME
   95        sdt           genunix                   callout_execute
callout-start
[skipped]
        Argument Types
                None                  <------ Why no more informations?

But for other Providers, "dtrace -lvf" does work, why?
# dtrace -lvf ip_input
   ID   PROVIDER            MODULE                          FUNCTION NAME
  779        mib                ip                          ip_input
ipInReceives
[skipped]
        Argument Types
                args[0]: int           <----- This is what I like to see.
.......
 
 
This message posted from opensolaris.org

> Hi gurus,
>
> Is there any easy way to know how many arguments a SDT probe has?   e.g.
>
> # dtrace -lvn callout-start
>   ID   PROVIDER            MODULE                       FUNCTION NAME
>   95        sdt           genunix                callout_execute
callout-start
> [skipped]
>        Argument Types
>                None                  <------ Why no more informations?
Sorry for the confusion.  Here is the deal:

There are two uses of the term "sdt".  One is in reference to the
provider
module sdt, i.e. a means of adding statically defined tracing to kernel
modules.  The sdt kernel module actually implements a family of DTrace
providers using this technique, including those labeled as provider
"sdt"
and those labeled as "proc", "io", and others.  (the fact
that these are
done by the sdt module is really just an implementation detail).

The second use of the term "sdt" is the literal provider name string
"sdt",
as in your example above.  When you see "sdt" in the PROVIDER part of
a probe
name, that refers to a group of Private kernel probes that are implemented
by the sdt provider module.  We don''t presently advertise the arguments
for
these Private probes (though we could do so; the fact that we don''t is
a
limitation/simplifying attribute of the current implementation).

So for sdt definition #2 right now, you need to use the source code to find
the arguments, and be aware that since this is Private they may change at
any time or the probe itself might disappear if the kernel changes.  Your
callout-start probe can be found here:

http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/callout.c#264

and you''ll see there is one argument, which is the callout_t *.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

Thanks.

For sdt definition #1, do you mean this file:
   
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/dtrace/sdt_subr.c

the (Provider) probe''s arg number & type is in sdt_args[], right?

For sdt definition #2, do you mean that those probes are just more or less for
internal use, no guarantee for them?

Can I ask a related question -
if I know the arg''s type, is there a *simple* action to print out the
whole structure?   just like mdb''s
"addr::print struct ..." or "addr::iphdr" or
"addr::mblk", etc.
I would image the D action is like:
printtype(type, arg);
 
 
This message posted from opensolaris.org

> Thanks.
> 
> For sdt definition #1, do you mean this file:
>    
>
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/dtrace/sdt_subr.c
> 
> the (Provider) probe''s arg number & type is in sdt_args[],
right?
Yes.  For sdt, that is the source of the dtrace -l -v information.
 
> For sdt definition #2, do you mean that those probes are just more or less
for i
> nternal use, no guarantee for them?   
Correct.  This is what Private means in our taxonomy of stability levels
(see the corresponding DTrace answerbook chapter for more info on that)
> Can I ask a related question -
> if I know the arg''s type, is there a *simple* action to print out
the whole stru
> cture?   just like mdb''s   
> "addr::print struct ..." or "addr::iphdr" or
"addr::mblk", etc.
> I would image the D action is like:
> printtype(type, arg);
Not at present, though an RFE is open on that.  You can print
individual members of interest using printf.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

OK, for sdt definition #2, is there any policy/strategy/limitation about adding
probes?   Can/should I add as many probes as I want, or just limit them along
the *interested* code path?     Can I use these probes to replace those
"ifdef DEBUG" code?


Talking about that RFE, can I know the RFE number?  Thanks.

-Alex
 
 
This message posted from opensolaris.org

On Sun, Aug 06, 2006 at 10:48:33PM -0700, Alex Peng
wrote:
> OK, for sdt definition #2, is there any policy/strategy/limitation
> about adding probes?  Can/should I add as many probes as I want, or
> just limit them along the *interested* code path?  Can I use these
> probes to replace those "ifdef DEBUG" code?
> Talking about that RFE, can I know the RFE number?  Thanks.
Could you please give enough context so that people can answer your questions?
It''s not clear what "definition #2" is, nor which RFE you are
referring
to.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

> On Sun, Aug 06, 2006 at 10:48:33PM -0700, Alex Peng
> wrote:
> > OK, for sdt definition #2, is there any
> policy/strategy/limitation
> > about adding probes?  Can/should I add as many
> probes as I want, or
> > just limit them along the *interested* code path?
>  Can I use these
>  probes to replace those "ifdef DEBUG" code?
> > Talking about that RFE, can I know the RFE number?
>  Thanks.
> Could you please give enough context so that people
> can answer your questions?
> It''s not clear what "definition #2" is, nor which RFE
> you are referring
> to.
> 
Sorry, those are in Michael''s previous reply.  
  http://www.opensolaris.org/jive/message.jspa?messageID=50268&tstart=0
  http://www.opensolaris.org/jive/message.jspa?messageID=50470&tstart=0

SDT def. #1 means those providers implemented via sdt, i.e. io, sched, proc;
SDT def. #2 means those probes implemented via DTRACE_PROBE*().    Most are
"Private".

RFE is  I am asking to have some "actions" like the dcmds in mdb, e.g.
      addr::print "struct ..."
or  addr::iphdr
or  addr::mblk

I would like to have some similar thing, so I don''t need to prepare
many "printf" for myself.   :)


Thanks,
-Alex

> Cheers,
> - jonathan
> 
> -- 
> Jonathan Adams, Solaris Kernel Development
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
 
 
This message posted from opensolaris.org

Jonathan,

Alex was referring to Mike''s posts.  It''s odd though that this
appears
as 2 seperate threads and I had no idea what he was refering to either
until I caught this other thread...

On 8/8/06, Jonathan Adams <jonathan.adams at sun.com>
wrote:
> On Sun, Aug 06, 2006 at 10:48:33PM -0700, Alex Peng wrote:
> > OK, for sdt definition #2, is there any policy/strategy/limitation
> > about adding probes?  Can/should I add as many probes as I want, or
> > just limit them along the *interested* code path?  Can I use these
> > probes to replace those "ifdef DEBUG" code?
>
> > Talking about that RFE, can I know the RFE number?  Thanks.
>
> Could you please give enough context so that people can answer your
questions?
> It''s not clear what "definition #2" is, nor which RFE
you are referring
> to.
>
> Cheers,
> - jonathan
>
> --
> Jonathan Adams, Solaris Kernel Development
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

-- 
Just me,
Wire ...