This page is here to serve as a scratch area for you to call out additions or enhancements that you'd like to see made to DTrace. Try and put as much detail as you can against any points you make (or at least enough to communicate the basics of the request). If you can already see the enhancement you wanted to add, make sure you add in a note to show your interest - the more people that want something, the more more likely it is to get done (well, that's the theory anyway!).
Remember that you are free to log [Request for Enhancements or Bugs|http://bugs.opensolaris.org] against DTrace. Depending on where your request lies, there are three category/sub-categories to choose from:
* kernel/dtrace
* library/libdtrace
* utility/dtrace
Bugs and RFE's to the [DTrace test suite|http://www.opensolaris.org/os/community/dtrace/dtest] should be logged against _utility/dtest_ .
h1. The Wish List
* Types for User-land. Making use of type (CTF and dwarf) information in user-land would give huge benefits, such as an args[] array for the pid provider and the ability to do auto-copyin (amongst other things).
* Ability to save the output of the ustack() and jstack() actions into a variable.
* Ability to modify args[] and/or uregs[] (see [RFE #5005776|http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5005776] and [this thread|https://cn.opensolaris.org/jive/thread.jspa?threadID=52476&tstart=120]). Some argue that DTrace is only meant to find (not fix) problems, but support for destructive actions suggests otherwise -- what else would you use them for? DTrace is already useful for temporary fixes... unless the problem lives in a register. DTrace scripts take minutes to write and affect live programs. By contrast, even the most responsive tech support would take some days to produce a patch, and most people would have to wait weeks, months, or forever for a fix to arrive.
Remember that you are free to log [Request for Enhancements or Bugs|http://bugs.opensolaris.org] against DTrace. Depending on where your request lies, there are three category/sub-categories to choose from:
* kernel/dtrace
* library/libdtrace
* utility/dtrace
Bugs and RFE's to the [DTrace test suite|http://www.opensolaris.org/os/community/dtrace/dtest] should be logged against _utility/dtest_ .
h1. The Wish List
* Types for User-land. Making use of type (CTF and dwarf) information in user-land would give huge benefits, such as an args[] array for the pid provider and the ability to do auto-copyin (amongst other things).
* Ability to save the output of the ustack() and jstack() actions into a variable.
* Ability to modify args[] and/or uregs[] (see [RFE #5005776|http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5005776] and [this thread|https://cn.opensolaris.org/jive/thread.jspa?threadID=52476&tstart=120]). Some argue that DTrace is only meant to find (not fix) problems, but support for destructive actions suggests otherwise -- what else would you use them for? DTrace is already useful for temporary fixes... unless the problem lives in a register. DTrace scripts take minutes to write and affect live programs. By contrast, even the most responsive tech support would take some days to produce a patch, and most people would have to wait weeks, months, or forever for a fix to arrive.