The LD_LIBRARY_PATH is because I am compiling Python as a shared lib and, of course, I am not installing the development version in the usual system path.

That is, it is not a requirement for this project, but an easy to follow procedure for unexperienced betatesters.

About the permissions, the situation is messy because under Solaris a regular user can not run dtrace unless special permissions be assigned to her. The situation is something like this: (talking about Solaris 10):

* Global Zone:
 - root: dtrace works.
 - Regular user: dtrace is going to show a "permission denied" error, unless an admin had set dtrace user/proc permissions to him. If that is the case, it works.

* Non Global Zone:
 - root: dtrace seems to work, but no probes can be found unless special dtrace user/proc permissions are assigned to the zone.
 - regular user: dtrace is going to show a "permission denied" error, unless an admin had set dtrace user/proc permissions to him. In that case, it will behave like "root". That is, no probes found unles the zone have the right capabilities.

The permission denied error can be easily detected and managed, but the "silent" error is not distinguible of this project not working. I am thinking about trying first an "always present" well known probe, to detect when the kernel is activelly ignoring dtrace instead of giving a clear permission error.

I have requested to the sysadmins of my OpenIndiana buildbots to activate dtrace (of user code) in my zone, so I can evaluate the behaviour under OpenIndiana/Illumos.

A couple of details I want to document here, to remember then and to ask for advice:

- I have added a "sys.trace_capabilities", so a program can know if any system-trace functionality is compiled in. Current values are "None" and "("dtrace", "Sun")". Maybe create a new "dtrace" module could be appropiate, instead, with "dtrace.supported=True/False", but I am thinking about future MacOS probes, Linux "systemtap" probes, etc.

- Current code only traces function calls *TO* Python code. If the function calls is to C code (os.getpid(), for instance), the call is not visible. I think this is a major deficience, apparently shared by all the previous attempts I have seen (including official Sun probes).