************************************************************************** * The following are notes for any script that uses the "fbt" provider. * To identify these scripts, check the "STABILITY" section of the script's * man page, or try grepping for "fbt" on the script. * * $Id: ALLfbt_notes.txt,v 1.1.1.1 2015/09/30 22:01:08 christos Exp $ * * COPYRIGHT: Copyright (c) 2007 Brendan Gregg. ************************************************************************** What is the "fbt" provider?... * A DTrace library of probes that instruments raw kernel function calls. * An "unstable" provider; meaning, scripts written using "fbt" are not guarenteed to work on future versions of the OS - including after patching the kernel. In a perfect world... * None of the DTraceToolkit scripts would use the "fbt" provider; instead they would all use stable providers such as "proc", "sched", "io", etc. * All the DTraceToolkit scripts would run on any system that supports DTrace. In the real world... * Not all stable providers exist yet. Many are in development, such as stable networking providers. * In the meantime, useful tools such as "tcpsnoop" and "tcptop" can only be written using the unstable "fbt" provider (and these scripts have broken several times due to kernel changes since they were first written). * "fbt" provider based scripts, - only run on a particular OS (eg, Solaris) - may only run on a particular version of an OS (eg, Solaris 10 3/05) - are likely to break for future OS releases (eg, Solaris 10 6/06) * "fbt" provider based scripts also make the impossible possible, albiet in a very unstable way, as a temporary solution while stable providers are still in development. * Once stable providers exist, "fbt" scripts can be rewritten to use them; however these new scripts will only run on newer OS builds that support the stable providers. (in other words, this won't help you if you remain on Solaris 10 6/06; you'll need to upgrade, or survive with "fbt"). * Only some of the DTraceToolkit scripts use "fbt", and only a portion of those have encountered stability issues - so this issue is limited. The "fbt" provider exports raw kernel implementation, which isn't guarenteed to be stable nor should it ever be (to do so would freeze kernel development and bug fixes). The only practical solution is the development and integration of stable providers (although that doesn't help people who keep running older versions of the OS). More harm than good?... Is the inclusion of these "fbt" scripts more harm than good? Consider, * the good, - shows what is possible with DTrace - should help a number of people solve specific performance issues, on systems where they run - a customer who really wants these scripts but on an OS version where they don't work, have at least the source as a starting point (and in some cases, the fix was trivial) * the bad, - teases and frustrates people who find these scripts don't work on their OS To minimise this issue, only a small number of "fbt" scripts have been included, and they have been documented (see their man page) as unstable. Can I help?... If you really like an "fbt" based script and would like to keep using it in a stable way, it may help to raise that with your vendor (Sun for Solaris, Apple for MacOS). Sun has OpenSolaris forums, such as dtrace-discuss, which are read by their engineers and the public.