dtrace discuss - Aug 2006 - SDT/USDT policies?

Hello,

If I release a new kernel module, do I need to release a SDT provider with it?  
Just like what "mdb" does - a mdb module together with the associated
kernel module.     Is it a "MUST" or a "OPTION"?

Also what''s the requirement of USDT and user application?   Is it
encouraged or not to have many probes inside the code?    Can I define my own
"action" for my own "provider"?

Thanks.
 
 
This message posted from opensolaris.org

Hi Alex,
> If I release a new kernel module, do I need to release a SDT provider
> with it?   Just like what "mdb" does - a mdb module together with
the
> associated kernel module.     Is it a "MUST" or a
"OPTION"?
It''s an option rather than a requirement, but one that you should
consider adding especially if there are diagnostic points that would be
interesting to a user or system administrator.
> Also what''s the requirement of USDT and user application?   Is it
> encouraged or not to have many probes inside the code?    Can I define
> my own "action" for my own "provider"?
We certainly encourage developers of application and libraries to add USDT
probes. The trick with any sort of static probes can be figuring out the
right ones. If anyone wants any feedback on probes they''re thinking of
adding, this forum is a great place to post that sort of question. There
have also been some questions about probes that classes of applications
could have in common (for example, it would be cool if databases had a
common set of probes in addition to their own specialized probes). It
would be great if someone working on adding probes to, say, MySQL wanted
to start that conversation.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Understand.

Given the truth that DTrace is an observability framework, and the disabled
probe doesn''t bring in any overhead, I would think to place probes at
diagnostic points or statistics points(as what MIB provider does) is a good
thing.

To push SDT/USDT been widely accepted would be a good example of Software
Group''s strategy - either through "service" or through
"training", and of course, the "community" work.   :)

-Alex
 
 
This message posted from opensolaris.org