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