dtrace discuss - Feb 2008 - how to get verbose stability/dependency information

Do you know if there is a way to get stability attributes
for registered dtrace probes except
dtrace -l -v ?

Because as far as I know while registering a usdt provider
there is a way to set stability attributes (name, data, dependency)
for provider, module, function, name and arguments of the probe.

Is there any way of getting all of this?
dtrace -l -v doesn''t seem verbose enough..
For instance, how can I get these attributes for a module or function?

thanks in advance,

Nikita Zinoviev

Do you know if there is a way to get stability attributes
for registered dtrace probes except
dtrace -l -v ?

Because as far as I know while registering a usdt provider
there is a way to set stability attributes (name, data, dependency)
for provider, module, function, name and arguments of the probe.

Is there any way of getting all of this?
dtrace -l -v doesn''t seem verbose enough..
For instance, how can I get these attributes for a module or function?

thanks in advance,

Nikita Zinoviev


--
This message posted from opensolaris.org

On Fri, Feb 08, 2008 at 03:35:04PM +0300, Nikita Zinoviev
wrote:
> Do you know if there is a way to get stability attributes
> for registered dtrace probes except
> dtrace -l -v ?
> 
> Because as far as I know while registering a usdt provider
> there is a way to set stability attributes (name, data, dependency)
> for provider, module, function, name and arguments of the probe.
> 
> Is there any way of getting all of this?
> dtrace -l -v doesn''t seem verbose enough..
> For instance, how can I get these attributes for a module or function?
> 
> thanks in advance,
> 
> Nikita Zinoviev
There is not a direct way of answering the question from the command-line
at present, although the C API to libdtrace does provide the info.
You can, however, sort of fudge your way to the answer like this:

If you run dtrace with -v but *not* -l (which says, expand all my probe
descriptions and list what probes match them) and then add -e to not
bother executing the query, you can get the stability info for the
composition of your probe description.  For example, if I want to
know the stability of just provider "fbt" I can do this:

# dtrace -P fbt -e -v

Stability attributes for description fbt:

        Minimum Probe Description Attributes
                Identifier Names: Unstable
                Data Semantics:   Unstable
                Dependency Class: Common

        Minimum Statement Attributes
                Identifier Names: Stable
                Data Semantics:   Stable
                Dependency Class: Common

fbt:::

Now suppose I want to know what happens if I were to give fbt a 
particular function (i.e. to see what effect composing the function
stability has).  I could change the above to this:

# dtrace -n fbt::kmem_alloc:entry -e -v

Stability attributes for description fbt::kmem_alloc:entry:

        Minimum Probe Description Attributes
                Identifier Names: Private
                Data Semantics:   Private
                Dependency Class: Unknown

        Minimum Statement Attributes
                Identifier Names: Stable
                Data Semantics:   Stable
                Dependency Class: Common

fbt::kmem_alloc:entry

        Probe Description Attributes
                Identifier Names: Private
                Data Semantics:   Private
                Dependency Class: Unknown

        Argument Attributes
                Identifier Names: Private
                Data Semantics:   Private
                Dependency Class: ISA

        Argument Types
                args[0]: size_t
                args[1]: int

Notice how the Probe Description attributes changed from
Unstable/Unstable/Common for fbt::: to Private/Private/Unknown.
So you can see that function names are Private.

That isn''t exactly as easy as we could have made it, so I could imagine
an RFE of the form "dtrace -P <provider> -v" should also show
the sub-
stability attributes associated with elements of that provider.

-Mike

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