DTrace Topics Providers
 DTrace Topics: Providers
This article is about DTrace Provider style and conventions, and is part of the DTrace Topics collection. A good understanding of DTrace is assumed knowledge, which can begin to be studied from the DTrace Topics: Intro section.
DTrace is a dynamic troubleshooting and analysis tool first introduced in the Solaris 10 and OpenSolaris operating systems.
DTrace has dynamic providers for instrumenting kernel and user-land code (fbt and pid), however since they export many thousands of raw function calls of an unstable interface, they can be difficult to use for anyone but the authors of the code. Stable (and static) providers, such as io, proc and syscall, improve usability as they export a small and sufficient number of high level probes and arguments, making DTrace observability as easy as possible for end users.
This page exists as a guide for developers of DTrace providers, to help them through the steps of choosing what is best to probe and how.
 List of Providers
Provider Description Who When fbt Function boundry tracing provider (kernel functions) Team DTrace (bmc) November 28, 2001 (SPARC) December 13, 2002 (x86) profile Profile provider Team DTrace (bmc) November 28, 2001 lockstat Lock statistics provider (kernel locks) Team DTrace (bmc) January 22, 2002 syscall System Call provider Team DTrace (bmc) August 23, 2002 sdt Statically Defined Tracing provider (kernel) Team DTrace (bmc) September 28, 2002 (SPARC) January 12, 2003 (x86) pid Process tracing provider Team DTrace (ahl) October 3, 2002 (SPARC) March 1, 2004 (x86) usdt User-land Statically Defined Tracing Team DTrace (ahl) August 31, 2004
 How to Write Providers
See DTrace Topics: USDT for user-land providers.
 Conventions and Style
 Provider Name
There are a number of points to consider while choosing an appropriate provider name:
What is the common name for the target that you are tracing?
Should the provider name convey a version number of the target?
This is harder to answer; Would future versions change observed functionality and change the probes that it exports? If so, can those probes be redesigned so that they remain the same for future versions?
There are different versions of NFS which perform different and incompatible operations - and so the providers are "nfsv3" and "nfsv4". However there are different versions of HTTP, but the core functionality (GET, POST, send, receive) doesn't change (although functionality may be added), making the provider name "http" a reasonable choice.
Is the protocol or functionality symmetric, or asymmetric?
HTTP is an asymmetric protocol. A client requests GETs, POSTs, HEADSs, and the server replies. Can the roles be reversed? Can the server send GETs to the client? No. Both the server and client have different functionality for the same protocol. Appropriate provider names would be "http" for the server and "http_client" for the client. They both can't be "http", and it makes more sense for the server provider to be called "http" than the client (optimizing for the common case - server tracing, and this also fits in with other providers); also, the convention is not to name these after their process names, eg "httpd".
TCP is a symmetric protocol. TCP functionality is the same for both the client application and the server application, as they both can send/receive/listen/connect in exactly the same way. The best name for this provider is "tcp".
A longer list of examples is below.
 Fits in
Does the provider name fit in with the list of existing providers?
 Provider Name List
The following is a list of current, future and imaginary providers, to illustrate conventions in provider naming.