Some of the proc probes listed in the SDTG proc:::fault proc:::start proc:::signal-clear are getting nastygrams under Mac OS X 10.5 (matches no probes), so I used the command "dtrace -l | grep proc" (and some editing) to produce: ... thread_terminate_self lwp-create ... fork create ... vfork create ... ctl_enqueuedata exec ... __mac_execve exec-failure ... posix_spawn exec-failure ... __mac_execve exec-success ... posix_spawn exec-success ... exit1 exit ... thread_terminate_internal lwp-exit ... thread_start_internal lwp-start ... gsignal signal-discard ... sendsig signal-handle ... postsig signal-handle ... gsignal signal-send Can some Apple expert tell me why these probes are missing? -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 Nov 25, 2007, at 4:53 PM, Rich Morin wrote:> Some of the proc probes listed in the SDTG > > proc:::fault > proc:::start > proc:::signal-clear > > are getting nastygrams under Mac OS X 10.5 (matches no probes), > so I used the command "dtrace -l | grep proc" (and some editing) > to produce: > > ... thread_terminate_self lwp-create > ... fork create > ... vfork create > ... ctl_enqueuedata exec > ... __mac_execve exec-failure > ... posix_spawn exec-failure > ... __mac_execve exec-success > ... posix_spawn exec-success > ... exit1 exit > ... thread_terminate_internal lwp-exit > ... thread_start_internal lwp-start > ... gsignal signal-discard > ... sendsig signal-handle > ... postsig signal-handle > ... gsignal signal-send > > Can some Apple expert tell me why these probes are missing?Rich, We''re having some internal "discussions" on the correct way to handle/implement these probes. They''re MIA now, in the worst case scenario we''ll add them back as non-functional stubs so scripts compile without errors. I hope to do better, but cannot promise any more than that :-(. James M
I''d _really_ like to see a page that describes (or at least lists) visible differences between the Leopard and Solaris versions of DTrace. -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
> We''re having some internal "discussions" on the correct way to > handle/implement these probes. They''re MIA now, in the worst case > scenario we''ll add them back as non-functional stubs so scripts compile > without errors. I hope to do better, but cannot promise any more than > that :-(.Making non-functional stubs would be an awful idea: scripts that don''t work would fail silently rather than aborting at startup. I''d much rather have a script complain on Mac OS X than do the wrong thing.> I''d _really_ like to see a page that describes (or at least > lists) visible differences between the Leopard and Solaris > versions of DTrace.This would be a great addition to the new DTrace wiki we''re working on. If folks from the Apple team are interested in participating, please drop me a note off list. Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
On Nov 26, 2007, at 8:38 AM, Adam Leventhal wrote:>> We''re having some internal "discussions" on the correct way to >> handle/implement these probes. They''re MIA now, in the worst case >> scenario we''ll add them back as non-functional stubs so scripts >> compile >> without errors. I hope to do better, but cannot promise any more than >> that :-(. > > Making non-functional stubs would be an awful idea: scripts that don''t > work would fail silently rather than aborting at startup. I''d much > rather have a script complain on Mac OS X than do the wrong thing.It''s not quite as awful as it seems at first blush. There is a slippery slope here as well. Suppose you''ve got a generic script (something like dtruss) that uses one of these probes, but not as a primary source of information. It might even just be pretty-printing data from that probe. If you''ve got stubs, the script will (mostly) work. Without them, bzzt. Worse, trying to fix it requires a pretty deep dive into Solaris and OS X, trying to understand why the probe is missing on one platform, what its meaning and usage imply, and how that might effect the rest of the script. Still not quite convincing, but consider the next step after this. If there isn''t a need to keep the documented providers in sync, what about the stable arguments? OS X doesn''t really share the concept of a LWP, even though it maps reasonably well onto a heavyweight thread. OS X doesn''t have a psinfo_t->pr_zoneid, the entire zone concept doesn''t exist. Should the OS X stable arguments data morph to better reflect what is and isn''t available in that platform? If we change that, how does that impact script portability? I could be convinced that we should each go our own way, but I''d like to have a little more real world usage data. James M
> >> We''re having some internal "discussions" on the correct way to > >> handle/implement these probes. They''re MIA now, in the worst case > >> scenario we''ll add them back as non-functional stubs so scripts > >> compile > >> without errors. I hope to do better, but cannot promise any more than > >> that :-(. > > > > Making non-functional stubs would be an awful idea: scripts that don''t > > work would fail silently rather than aborting at startup. I''d much > > rather have a script complain on Mac OS X than do the wrong thing. > > It''s not quite as awful as it seems at first blush. There is a slippery > slope here as well. > > Suppose you''ve got a generic script (something like dtruss) that > uses one of these probes, but not as a primary source of information. > It might even just be pretty-printing data from that probe.If that''s the case -- if the script is truly not relying on the probe for correctness -- then it should specify the "zdefs" option, via either "#pragma D options zdefs" or "-Z".> If you''ve got stubs, the script will (mostly) work. Without them, > bzzt. > Worse, trying to fix it requires a pretty deep dive into Solaris and > OS X, > trying to understand why the probe is missing on one platform, what its > meaning and usage imply, and how that might effect the rest of the > script. > > Still not quite convincing, but consider the next step after this. If > there > isn''t a need to keep the documented providers in sync, what about the > stable > arguments? OS X doesn''t really share the concept of a LWP, even though > it maps reasonably well onto a heavyweight thread. OS X doesn''t have > a psinfo_t->pr_zoneid, the entire zone concept doesn''t exist.Zone ID may not be a good example of what you''re talking about -- for pr_zoneid, I think you should act as a Solaris machine would if it had no installed zones. (That is, always return 0 for pr_zoneid to denote the global zone.) There may be more convincing examples where there is no mapping in the OS X world, but I find it hard to accept that you shouldn''t just refuse to translate such members and let the compile fail.> Should the OS X stable arguments data morph to better reflect what is > and isn''t available in that platform? If we change that, how does that > impact > script portability?No, please do not morph stable, translated arguments -- either implement the analogue as it exists in OS X or fail to translate the member (or implement the probe, in the case of some of these proc probes). We are not recklessly adding translated arguments and stable probes -- these are designed to represent principles that transcend implementation, and should therefore be representable is a large range of systems. If this is not the case -- if a stable probe or argument has no analogue -- you should not implement it rather than warp the extant definition. And remember: you are free to add your own SDT providers if you wish to capture semantics more specific to your implementation... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
On Nov 26, 2007, at 11:09 AM, Bryan Cantrill wrote:> > Zone ID may not be a good example of what you''re talking about -- for > pr_zoneid, I think you should act as a Solaris machine would if it had > no installed zones. (That is, always return 0 for pr_zoneid to > denote the > global zone.) There may be more convincing examples where there is no > mapping in the OS X world, but I find it hard to accept that you > shouldn''t > just refuse to translate such members and let the compile fail.Yes, I just remembered a much better example: curpsinfo->pr_psargs The data needed to properly populate this field does not exist in OS X. Should DTTk''s newproc.d fail to compile, or should it produce the marginally useful: ghopper:/# newproc.d dtrace: script ''/usr/bin/newproc.d'' matched 2 probes CPU ID FUNCTION:NAME 0 18481 __mac_execve:exec-success sh 0 18481 __mac_execve:exec-success hostname 0 18481 __mac_execve:exec-success bash 0 18481 __mac_execve:exec-success id 1 18481 __mac_execve:exec-success login 1 18481 __mac_execve:exec-success cat 3 18481 __mac_execve:exec-success tcsh I''m certain there are other equally annoying areas of impedance mismatch, its just been a long time since I had this discussion and don''t remember them all. James M
Hey James,> >Zone ID may not be a good example of what you''re talking about -- for > >pr_zoneid, I think you should act as a Solaris machine would if it had > >no installed zones. (That is, always return 0 for pr_zoneid to > >denote the > >global zone.) There may be more convincing examples where there is no > >mapping in the OS X world, but I find it hard to accept that you > >shouldn''t > >just refuse to translate such members and let the compile fail. > > Yes, I just remembered a much better example: > > curpsinfo->pr_psargsI knew that there had to be a good example out there... ;)> The data needed to properly populate this field does not exist in > OS X. Should DTTk''s newproc.d fail to compile, or should it produce > the marginally useful: > > ghopper:/# newproc.d > dtrace: script ''/usr/bin/newproc.d'' matched 2 probes > CPU ID FUNCTION:NAME > 0 18481 __mac_execve:exec-success sh > 0 18481 __mac_execve:exec-success hostname > 0 18481 __mac_execve:exec-success bash > 0 18481 __mac_execve:exec-success id > 1 18481 __mac_execve:exec-success login > 1 18481 __mac_execve:exec-success cat > 3 18481 __mac_execve:exec-success tcsh > > I''m certain there are other equally annoying areas of impedance > mismatch, its just been a long time since I had this discussion and > don''t > remember them all.I think with cases like these, we should all just collectively hash out here (that is, dtrace-discuss) what we expect to see. I think you could make an argument either way in this case -- certainly, a script could rely on pr_psargs to actually be the args (of course), but a script could also be using this as a fuller execname. Given that we in Solaris only record the first 80 characters of this (that is, given that it isn''t strictly speaking complete anyway), I think my bias would be that you do the best you can with pr_psargs -- and if that''s only the execname, so be it. Others'' thoughts? - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Sun Microsystems FishWorks. http://blogs.sun.com/bmc
On Mon, Nov 26, 2007 at 11:28:53AM -0800, Bryan Cantrill wrote:> I think my bias would be that you do the best you can with > pr_psargs -- and if that''s only the execname, so be it. Others'' thoughts?+1 -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl