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
_______________________________________________
dtrace-discuss mailing list
[email protected]
