[dtrace-discuss] Re: dtrace in my kernel module, what''s the problem?

Matthias Pfützner - Data Center Ambassador - Strategy and Technology
2006-01-12T13:02:17Z

On on this topic...

I found:

        http://www.opensolaris.org/jive/thread.jspa?threadID=1391&tstart=210

but that still misses stuff for me to understand it completely.

a.) Do I need to LINK (ld) something to the binaries?
b.) Can I create own new probes? (If so, how?)

Because the section in the docs is WAY TO BRIEF (aka, no examples!):

Creating SDT Probes

If you are a device driver developer, you might be interested in creating your
own SDT probes in your Solaris driver. The disabled probe effect of SDT is
essentially the cost of several no-operation machine instructions. You are
therefore encouraged to add SDT probes to your device drivers as needed. Unless
these probes negatively affect performance, you can leave them in your shipping
code.
Declaring Probes

SDT probes are declared using the DTRACE_PROBE, DTRACE_PROBE1, DTRACE_PROBE2,
DTRACE_PROBE3 and DTRACE_PROBE4 macros from <sys/sdt.h>. The module name
and function name of an SDT-based probe corresponds to the kernel module and
function of the probe. The name of the probe depends on the name given in the
DTRACE_PROBEn macro. If the name contains no two consecutive underbars (__), the
name of the probe is as written in the macro. If the name contains any two
consecutive underbars, the probe name converts the consecutive underbars to a
single dash (-). For example, if a DTRACE_PROBE macro specifies
transaction__start, the SDT probe will be named transaction-start. This
substitution allows C code to provide macro names that are not valid C
identifiers without specifying a string.

DTrace includes the kernel module name and function name as part of the tuple
identifying a probe, so you do not need to include this information in the probe
name to prevent name space collisions. You can use the command dtrace -l -P sdt
-m module on your driver module to list the probes you have installed and the
full names that will be seen by users of DTrace.
Probe Arguments

The arguments for each SDT probe are the arguments specified in the
corresponding DTRACE_PROBEn macro reference. The number of arguments depends on
which macro was used to create the probe: DTRACE_PROBE1 specifies one argument,
DTRACE_PROBE2 specifies two arguments, and so on. When declaring your SDT
probes, you can minimize their disabled probe effect by not dereferencing
pointers and not loading from global variables in the probe arguments. Both
pointer dereferencing and global variable loading may be done safely in D
actions that enable probes, so DTrace users can request these actions only when
they are needed.

And: The section on "Declaring Probes" only states:

The module name and function name of an SDT-based probe corresponds to the
kernel module and function of the probe. The name of the probe depends on the
name given in the DTRACE_PROBEn macro.

Which probes are allowed?

And, looking at the SDT probes, there are only 4:

        callout-start
        callout-end
        interrupt-start
        interrupt-complete

That''s not really, what I''m looking for (or thinking a doc
should look
like)...

Looking at the nvidia driver, it has something like 40000 probes based on the
FBT provider, but the doc to the FBT provider is even more brief, than the sdt
docs... (will say, the is NO docu on how to register my driver with the fgt
provider...)

You see, the dtrace docs et.al. are all very think, but do cover only the
"end-user" side very well. It does NOT yet help kernel/driver
developpers very
well... ;-(

So, still: I need help!

        Matthias

I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:
> Perhaps I need to ask the question differently:
>
> What do I need to do to enable a kernel driver to be dtrace-able?
>
> Aka: What code do I need to put into the kernel driver source, so that it
> becomes accessable via dtrace?
>
> I already learned, that my kernel driver will not become a new provider,
> that''s OK.
>
> I already learned, that i need to "somehow register" my
variables, routines,
> whatever to be "seen" by the dtrace kernel stuff...
>
> So, a "HowTo" for driver developpers might be helpful! (As I have
been
> searching now for hours, but didn''t find any easy to follow
guidelines
> yet... ;-( )
>
>         Matthias
>
> I (Matthias Pf?tzner - Data Center Ambassador - Strategy and Technology)
wrote:
> > It can''t be that chapter...
> >
> > Because it starts:
> >
> > The Statically Defined Tracing (SDT) provider creates probes at sites
that a software programmer has formally designated. The SDT mechanism allows
programmers to consciously choose locations of interest to users of DTrace and
to convey some semantic knowledge about each location through the probe name.
The Solaris kernel has defined a handful of SDT probes, and will likely add more
over time. DTrace also provides a mechanism for user application developers to
define static probes, described in Chapter 34, Statically Defined Tracing for
User Applications.
> >
> > Still curious (and now, for the first time to the dtrace-alias),
> >         Matthias
> >
> > I (Matthias Pf?tzner - Data Center Ambassador - Strategy and
Technology) wrote:
> > > Adam,
> > >
> > > the problem is clear to me, but i didn''t find the kernel
chapter... ;-)
> > >
> > > Here''s the TOC:
> > >
> > >     * Index
> > >     * Book Information
> > >     * Preface
> > >     * 1.  Introduction
> > >     * 2.  Types, Operators, and Expressions
> > >     * 3.  Variables
> > >     * 4.  D Program Structure
> > >     * 5.  Pointers and Arrays
> > >     * 6.  Strings
> > >     * 7.  Structs and Unions
> > >     * 8.  Type and Constant Definitions
> > >     * 9.  Aggregations
> > >     * 10.  Actions and Subroutines
> > >     * 11.  Buffers and Buffering
> > >     * 12.  Output Formatting
> > >     * 13.  Speculative Tracing
> > >     * 14.  dtrace(1M) Utility
> > >     * 15.  Scripting
> > >     * 16.  Options and Tunables
> > >     * 17.  dtrace Provider
> > >     * 18.  lockstat Provider
> > >     * 19.  profile Provider
> > >     * 20.  fbt Provider
> > >     * 21.  syscall Provider
> > >     * 22.  sdt Provider
> > >     * 23.  sysinfo Provider
> > >     * 24.  vminfo Provider
> > >     * 25.  proc Provider
> > >     * 26.  sched Provider
> > >     * 27.  io Provider
> > >     * 28.  mib Provider
> > >     * 29.  fpuinfo Provider
> > >     * 30.  pid Provider
> > >     * 31.  plockstat Provider
> > >     * 32.  fasttrap Provider
> > >     * 33.  User Process Tracing
> > >     * 34.  Statically Defined Tracing for User Applications
> > >     * 35.  Security
> > >     * 36.  Anonymous Tracing
> > >     * 37.  Postmortem Tracing
> > >     * 38.  Performance Considerations
> > >     * 39.  Stability
> > >     * 40.  Translators
> > >     * 41.  Versioning
> > >     * Glossary
> > >
> > > Which chapter is the kernel tracing developing
"info-container"? The "sdt"
> > > chapter, aka chapter 22?
> > >
> > > Still curious...
> > >
> > >         Matthias
> > >
> > > You (Adam Leventhal) write:
> > > > Hi Matthias,
> > > >
> > > > Please post this question to dtrace-discuss at
opensolaris.org, but the short
> > > > answer is that USDT is just for _user_ land binaries; for
(kernel) SDT
> > > > check that chapter in the Solaris Dynamic Tracing Guide.
> > > >
> > > > Adam
> > > >
> > > > On Wed, Jan 11, 2006 at 09:46:45PM +0100, Matthias Pftzner -
Data Center Ambassador - Strategy and Technology wrote:
> > > > > Folks,
> > > > >
> > > > > I try to add dtrace points to "my" kernel
module, but do get errors during
> > > > > the compile.
> > > > >
> > > > >         /usr/sbin/dtrace -G -32 -s saa713xdtrace.d
obj-i386/saa713x-core.o obj-i386/saa713x-video.o obj-i386/saa713x-cards.o
obj-i386/saa713x-tvaudio.o obj-i386/saa713x-i2c.o
> > > > >         dtrace: failed to link script saa713xdtrace: an
error was encountered while processing obj-i386/saa713x-core.o
> > > > >
> > > > > Here''s the code:
> > > > >
> > > > > bash-3.00$ cat saa713xdtrace.d
> > > > > provider saa713xdtrace {
> > > > >         probe routine__enter(string);
> > > > >         probe routine__exit(string);
> > > > > };
> > > > > bash-3.00$
> > > > >
> > > > > And in the file saa713x-core.c I do have:
> > > > >
> > > > > #include <sys/sdt.h>
> > > > >
> > > > > void saa713x_print_ioctl(char *name, unsigned int cmd)
> > > > > {
> > > > >         const char *cmdnm;
> > > > >         char *dir = "??";
> > > > >
> > > > >         DTRACE_PROBE1(saa713xdtrace, routine__enter,
"saa713x_print_ioctl");
> > > > >         /*
> > > > >          * IOR/read  == IOC_OUT == kernel->user
> > > > >          * IOW/write == IOC_IN  == user->kernel
> > > > >          */
> > > > >         switch (cmd & IOC_INOUT) {
> > > > >
> > > > > et.al...
> > > > >
> > > > > So, what''s the problem, the error message
isn''t really helpful... ;-(
> > > > >
> > > > > All infos I found on this stuff is in:
> > > > >
> > > > >
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
> > > > >
> > > > > Is there more? I did not find anything under:
> > > > >
> > > > >         http://www.sun.com/bigadmin/content/dtrace/
> > > > >
> > > > > Clueless,
> > > > >         Matthias
> > > > > --
> > > > >
***********************************************************************
> > > > > Matthias Pf?tzner
> > > > > Data Center Ambassador
> > > > > Strategy & Technology
> > > > > Sun Microsystems GmbH                 Tel: +49 6103
752-394 (x65394)
> > > > > Amp?restra?e 6                        Mobile: +49 172
8428766
> > > > > 63225 Langen                          Fax: +49 6103
752-167
> > > > > Germany
mailto:Matthias.Pfuetzner at Sun.COM
> > > > >
***********************************************************************
> > > >
> > > > --
> > > > Adam Leventhal, Solaris Kernel Development