> On Wed, 27 Dec 2006, Garrett D'Amore wrote:
>
> [ ... ]
> > A better way, IMO, would be to create a new global symbol, "_debug" or
> > somesuch, that is an integer providing the value. This could be
> > overridden using the "normal" methods, and would also avoid any
> > compatibility issues in extending modlinkage.
>
> How about a "dprintf DTrace provider" ? I'm dreaming of an interface like
> this:
>
> Use DTRACE_DPRINTF(level, ...) in your sourcecode, and enable it via
> probes like:
>
> dprintf:mymodule:tracedfunc: /level >= xx/ { }
>
> Can this be done ? Don't care whether the above gives me the debug
> messages in syslog or on the dtrace output. I just want the dynamic
> level-based enabling.
>
> FrankH.
Let me provide some guidance here:
1. The place to start isn't actually by adding something, but by deleting
things. Most of the debug printf stuff in the kernel that exists today,
predating DTrace, is trivially replaceable by a simple DTrace script,
since much of it does something like report function entry arguments.
All of that should be ripped out -- as should anything else for which
one can trivially write the DTrace script or grab it from opensolaris.org.
The format string is typically of no value for such things anyway, and
of course DTrace permits each user/use case to format as they require,
which is likely to be different for different uses.
2. If existing DTrace providers don't provide access to what is needed, the
next best choice is to use SDT in the kernel to add *generic* SDT probes
with the data of interest, while also applying DTrace principles to limit
the disabled probe effect. For example, don't dereference any pointers to
get arguments, since you can do those dereferences from D only when
instrumentation is enabled. Generic SDT probes can be added at any time
by kernel developers, and are significantly higher-leverage than any sort
of format-string based mechanism, because they can be used *either* in a
simple D program with printf() to get the effect of "dprintf", or be
leveraged in much more interesting ways by other D scripts or layered tools.
3. There are some cases where a large body of traditional "dprintf" may
have value beyond (1) and (2): an example might be a significantly well-
thought out collection of things in a group, where the formatting code
is actually adding information by converting something to a readable format.
(please take a conservative viewpoint here when looking at these things)
In this case, a better solution would be to rewrite that stuff as a DTrace
script that could be placed in a common location in the filesystem, and perhaps
with some standard SDT provider name (as Frank suggests above) or with a
simple wrapper script for enabling. The other missing piece which may be
needed to help is kernel-side is-enabled probes, which Adam has been
thinking about. In any case, it's much more useful to have the format
string bindings live in a particular userland .d file because:
(a) it permits their evolution without needed to rebuild the kernel
(b) it permits multiple developers to have different ones
(c) it permits the probe code to be higher leverage as in (2)
If someone is interested in (3), we can discuss further here or on
dtrace-discuss. Personally, I'd like to see people spend time on (1)
(as long as you're an active developer in the area or it is unowned) and (2).
If someone has examples of something that fits (3), it might be useful also
to talk about them to explain what if any features are required that
can't already be trivially implemented with existing D scripts.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
