dtrace discuss - Mar 2008 - Putting Wish List items on the DTrace wiki?

I have compiled a "Wish List" of things I''d like to see fixed
or added in DTrace, Mac OS X DTrace, etc:

  http://cfcl.com/twiki/bin/view/Projects/DT_Logger/Wish_List

It seems appropriate to put these onto the DTrace wiki, but I
don''t see any place allocated for this purpose (and I''d rather
not interfere with the existing organization).

Could someone involved with the wiki layout let me know where
this sort of information should go?

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

[ I posted this a week ago, but haven''t seen any response.

  Now that the DTrace "movers and shakers" are done setting
  up dtrace.conf(8) (and a fine unconference it was!), can
  someone give me some direction in setting up some pages?

  Who knows, maybe others will follow my lead and post their
  own "wish list" items... -r ]


I have compiled a "Wish List" of things I''d like to see fixed
or added in DTrace, Mac OS X DTrace, etc:

  http://cfcl.com/twiki/bin/view/Projects/DT_Logger/Wish_List

It seems appropriate to put these onto the DTrace wiki, but I
don''t see any place allocated for this purpose (and I''d rather
not interfere with the existing organization).

Could someone involved with the wiki layout let me know where
this sort of information should go?

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

> [ I posted this a week ago, but haven''t seen any response.
> 
>   Now that the DTrace "movers and shakers" are done setting
>   up dtrace.conf(8) (and a fine unconference it was!), can
>   someone give me some direction in setting up some pages?
> 
>   Who knows, maybe others will follow my lead and post their
>   own "wish list" items... -r ]
I posted reply, but don''t recall seeing it here. My wishlist:

6496550 DTrace needs a way to get time linear sequential output on multi-cpu
systems.
 - if you have more than one cpu core, dtrace output is just a mess. You
   have to trace(timestamp) in every probe and later sort the output by
   cat output | sed -e ''s/^ *[^ ]* *[^ ]* *//'' | sort -n +1
> sorted

6314638 Dtrace needs a packet dumper
 - if you ever tried to dump mblk_t structures in streams module, you
   know what I''m talking about

5059507 watchpoint provider
 - That would be nice, but falls a bit out of dtrace scope, as the
   probes would have to be generated during dtrace run. But how sweet
   would be this?

  pid$target::malloc:entry
  /self->is_inside_my_function/
  {
        self->x = 1;
  }

  pid$target::malloc:return
  /self->is_inside_my_function && self->x/
  {
        add_watchpoint("my_memory", arg0, 10)
  }

  watchpoint:my_memory:write:entry
  {
        printf("Culprit ! Memory %p is being changed\n", arg0);
        printf("Previous value = %c", stringof(copyin(arg0, 1)));
        ustack();
  }

  watchpoint:my_memory:write:return
  {
        printf("new value = %c", stringof(copyin(arg0, 1)));
  }

Thanks

-- 
	Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080318/6537cdc1/attachment.bin>

My wish list: (not strictly DTrace limitations, but related)

	1. Since the pid provider takes instruction addresses, I
	   wish that there was a reliable and easy method to
	   determine the line number in the source given the
	   address and vice versa. The dbx program does this, so
	   it must be possible. In fact, the right compilation
	   and linker flags, maybe DTrace could do this right in
	   the pid provider!

	2. Comprehensive data symbol information in CTF for the
	   kernel. Right now, DTrace cannot find any of the symbols
	   that are defined in .s files in the kernel. Even if you
	   provide the address manually, it does not know the data
	   type. So, this wish is two-fold. One, give the user a
	   way to manually tell DTrace a symbol address and data
	   type and let it treat this symbol as a first class
	   symbol from then on. And two, add some kind of macro
	   to the assembler so it would generate whatever it needs
	   to in the resulting object files to allow the variables
	   in .s files to play in the CTF game.
-- 
blu

There are two rules in life:
Rule 1- Don''t tell people everything you know
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

>
>My wish list: (not strictly DTrace limitations, but related)
>
>	1. Since the pid provider takes instruction addresses, I
>	   wish that there was a reliable and easy method to
>	   determine the line number in the source given the
>	   address and vice versa. The dbx program does this, so
>	   it must be possible. In fact, the right compilation
>	   and linker flags, maybe DTrace could do this right in
>	   the pid provider!
There''s a one to many mapping, so which instruction would you want to
instrument?  (the compiler will completely rearrange the instruction
stream).
>	2. Comprehensive data symbol information in CTF for the
>	   kernel. Right now, DTrace cannot find any of the symbols
>	   that are defined in .s files in the kernel. Even if you
>	   provide the address manually, it does not know the data
>	   type. So, this wish is two-fold. One, give the user a
>	   way to manually tell DTrace a symbol address and data
>	   type and let it treat this symbol as a first class
>	   symbol from then on. And two, add some kind of macro
>	   to the assembler so it would generate whatever it needs
>	   to in the resulting object files to allow the variables
>	   in .s files to play in the CTF game.

For which kernel variables is this a limitation?

As there''s a fairly easy work around: define all globals in a .c file,
I would not necessarily see this as an important restriction.

Casper

Casper.Dik at Sun.COM wrote:
>> My wish list: (not strictly DTrace limitations, but related)
>>
>> 	1. Since the pid provider takes instruction addresses, I
>> 	   wish that there was a reliable and easy method to
>> 	   determine the line number in the source given the
>> 	   address and vice versa. The dbx program does this, so
>> 	   it must be possible. In fact, the right compilation
>> 	   and linker flags, maybe DTrace could do this right in
>> 	   the pid provider!
> 
> There''s a one to many mapping, so which instruction would you want
to
> instrument?  (the compiler will completely rearrange the instruction
> stream).
I would be happy with any of them. First would probably be best. Any 
would work for me too.
> 
>> 	2. Comprehensive data symbol information in CTF for the
>> 	   kernel. Right now, DTrace cannot find any of the symbols
>> 	   that are defined in .s files in the kernel. Even if you
>> 	   provide the address manually, it does not know the data
>> 	   type. So, this wish is two-fold. One, give the user a
>> 	   way to manually tell DTrace a symbol address and data
>> 	   type and let it treat this symbol as a first class
>> 	   symbol from then on. And two, add some kind of macro
>> 	   to the assembler so it would generate whatever it needs
>> 	   to in the resulting object files to allow the variables
>> 	   in .s files to play in the CTF game.
> 
> 
> For which kernel variables is this a limitation?
> 
> As there''s a fairly easy work around: define all globals in a .c
file,
> I would not necessarily see this as an important restriction.
The fact that it should be easy to fix doesn''t change the fact that it 
should be fixed. Which reminds me, DTrace doesn''t read CTF info for 
user executables, right? If not, it should.
> 
> Casper
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
blu

There are two rules in life:
Rule 1- Don''t tell people everything you know
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

>The fact that it should be easy to fix doesn''t change the fact that
it
>should be fixed. Which reminds me, DTrace doesn''t read CTF info for
>user executables, right? If not, it should.

It''s not necessarily "easy to fix".  Easy to workaround,
perhaps./

But you sidestep the more important question I asked: how big of a problem 
is it really?  How many variables are defined in .s files?

Casper

Casper.Dik at Sun.COM wrote:
> 
>> The fact that it should be easy to fix doesn''t change the fact
that it
>> should be fixed. Which reminds me, DTrace doesn''t read CTF
info for
>> user executables, right? If not, it should.
> 
> 
> It''s not necessarily "easy to fix".  Easy to workaround,
perhaps./
> 
> But you sidestep the more important question I asked: how big of a problem 
> is it really?  How many variables are defined in .s files?
> 
> Casper
> 
I don''t know really. But it seems like all the ones I am ever 
interested in are. 8-)

However, it seems to me to be an obvious extension. If I presume that 
CTF info was sufficiently useful to have been worth creating in the 
first place, and that new tools will be made that use the info, then 
allowing the assembly source files to play in that space is only 
logical. It seems like it would be relatively simple to add the info 
to the object files produced by the assembler. In fact, a quick look 
at some of the source files shows that much of the info is already 
there, apparently for the use of lint.
-- 
blu

There are two rules in life:
Rule 1- Don''t tell people everything you know
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Rich,

Could you please add this to the wishlist:

* an option to print the module name when printing out
  function trace points, so rather than seeing just:
  0                -> mutex_init

  I would get to see this:
  0   ip           -> mutex_init

Darren

Hi Rich,

In case you weren''t aware, you can view and log RFE''s
(Requests for Enhancements) via bugs.opensolaris.org. However,
this interface is a bit limited and I do understand it''s probably
not the greatest way to interact with the bug tracking system
that we use.

I''m quite open to there being an area on the wiki where
anyone could detail features they''d like added or modified
(a "wish list" if you will). I''m not sure how that would look
over time but the more feedback we have on what people want,
the better.

It may also be good to add an area which list or details
manageable bugs/RFE''s that may be good for community members
to work on if they wanted to dip their toe into DTrace development.

If nobody has any strong objections or better ideas in the
next few days, I''ll add these to the wiki.

Jon.
> [ I posted this a week ago, but haven''t seen any response.
>
>   Now that the DTrace "movers and shakers" are done setting
>   up dtrace.conf(8) (and a fine unconference it was!), can
>   someone give me some direction in setting up some pages?
>
>   Who knows, maybe others will follow my lead and post their
>   own "wish list" items... -r ]
>
>
> I have compiled a "Wish List" of things I''d like to see
fixed
> or added in DTrace, Mac OS X DTrace, etc:
>
>   http://cfcl.com/twiki/bin/view/Projects/DT_Logger/Wish_List
>
> It seems appropriate to put these onto the DTrace wiki, but I
> don''t see any place allocated for this purpose (and I''d
rather
> not interfere with the existing organization).
>
> Could someone involved with the wiki layout let me know where
> this sort of information should go?
>
> -r
>

Hi Rich,

Apologies for taking a while but I''ve put a page on the
DTrace wiki space where one and all can record their
deepest desires (purely for DTrace enhancements though!).

http://wikis.sun.com/display/DTrace/The+Wish+List

Jon.
> [ I posted this a week ago, but haven''t seen any response.
>
>   Now that the DTrace "movers and shakers" are done setting
>   up dtrace.conf(8) (and a fine unconference it was!), can
>   someone give me some direction in setting up some pages?
>
>   Who knows, maybe others will follow my lead and post their
>   own "wish list" items... -r ]
>
>
> I have compiled a "Wish List" of things I''d like to see
fixed
> or added in DTrace, Mac OS X DTrace, etc:
>
>   http://cfcl.com/twiki/bin/view/Projects/DT_Logger/Wish_List
>
> It seems appropriate to put these onto the DTrace wiki, but I
> don''t see any place allocated for this purpose (and I''d
rather
> not interfere with the existing organization).
>
> Could someone involved with the wiki layout let me know where
> this sort of information should go?
>

At 14:45 +0400 4/3/08, Jon Haslam wrote:
> Apologies for taking a while but I''ve put a page on the
> DTrace wiki space where one and all can record their
> deepest desires (purely for DTrace enhancements though!).
>
> http://wikis.sun.com/display/DTrace/The+Wish+List
Thanks for putting up the page.  I''ll fold some content into it
this evening.  Perhaps some of the folks who sent in content
will add it to the page (or fix my additions :-).

However, I must make a meta-comment.  This wiki (Confluence)
has some real drawbacks.  Why isn''t Sun using a time-tested,
Open Source, Enterprise wiki such as TWiki?

For example, I _really_ looked at the documentation and found
NO way to add line breaks in the markup text without producing
line breaks in the formatted page.  This is unfortunate, not
to mention fascist...  And, because Confluence appears to be a
proprietary offering, we get to live with it until THEY choose
to provide a workaround.  Grumble.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

At 19:26 -0800 4/3/08, Rich Morin wrote:
> This wiki (Confluence) has some real drawbacks.
  -  There seems to be no way to tell the wiki to format
     span (ie, inline) elements in <tt>monospace</tt> font.

  -  Although there is a link to Advanced Macros in the
     docs, some of the items described (eg, "{html}") aren''t
     recognized by the wiki software.  So, bad code AND bad
     documentation...

  -  As the enclosure demonstrates, the formatting need love.

For yucks, I transliterated some of the page content into
TWiki, so that folks can see some of what I''d like to be able
to do in the way of formatting:

http://cfcl.com/twiki/bin/view/Projects/DT_Logger/Transcoded_Confluence
http://cfcl.com/twiki/bin/view/Projects/DT_Logger/Transcoded_Confluence?raw=on

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: %SS_TWL_fmt.png
Type: application/applefile
Size: 124 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080403/70066d00/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SS_TWL_fmt.png
Type: application/octet-stream
Size: 5180 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080403/70066d00/attachment.obj>

> However, I must make a meta-comment.  This wiki (Confluence)
> has some real drawbacks.  Why isn''t Sun using a time-tested,
> Open Source, Enterprise wiki such as TWiki?
We just have to use the infrastructure that''s provided so
there''s
not a lot that we can do for now. Your points are duly noted
though and I''ll pass your feedback along to the people who manage
this stuff.

Jon.

Let me add to that:  One of the top priorities that came out of the recent 
OpenSolaris vote was "Deploy a public wiki on opensolaris.org.".  So,
that
should be looked at shortly....

Mike

Jon Haslam wrote:
>> However, I must make a meta-comment.  This wiki (Confluence)
>> has some real drawbacks.  Why isn''t Sun using a time-tested,
>> Open Source, Enterprise wiki such as TWiki?
> 
> We just have to use the infrastructure that''s provided so
there''s
> not a lot that we can do for now. Your points are duly noted
> though and I''ll pass your feedback along to the people who manage
> this stuff.
> 
> Jon.
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Michael Pogue wrote:
> Let me add to that:  One of the top priorities that came out of the recent 
> OpenSolaris vote was "Deploy a public wiki on opensolaris.org.". 
So, that
> should be looked at shortly....
It was voted highly last year too - don''t count on any OpenSolaris wiki
other
than genunix.org anytime soon - it''s simply not in the plans/resources,
and the
priority poll has little say in changing those.

-- 
     -Alan Coopersmith-           alan.coopersmith at sun.com
      Sun Microsystems, Inc. - X Window System Engineering

At 22:26 -0700 4/6/08, Alan Coopersmith wrote:
> It was voted highly last year too - don''t count on any
> OpenSolaris wiki other than genunix.org anytime soon -
> it''s simply not in the plans/resources, and the
> priority poll has little say in changing those.
Well, it isn''t important enough to me to want to start a
fracas inside Sun, but I will observe that finding a site
willing to host a DTrace TWiki should be pretty easy...

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

On Apr 6, 2008, at 11:58 PM, Rich Morin wrote:
> At 22:26 -0700 4/6/08, Alan Coopersmith wrote:
>> It was voted highly last year too - don''t count on any
>> OpenSolaris wiki other than genunix.org anytime soon -
>> it''s simply not in the plans/resources, and the
>> priority poll has little say in changing those.
>
> Well, it isn''t important enough to me to want to start a
> fracas inside Sun, but I will observe that finding a site
> willing to host a DTrace TWiki should be pretty easy...
There actually had been several other DTrace wikis, but we wanted
to use wikis.sun.com as the definitive DTrace wiki where we could
accumulate all the official information for and by the community.
While the wiki software may not be ideal, it''s certainly good enough.
We''ll move the wiki once wikis.opensolaris.org becomes a reality,
but until then I think we''ll scrape by with what we''ve got.

Adam


--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl