Hi Stan,
----- Original Message -----
>
> > Should we expect the patch to build on Mac OS X? OOC, do you know if the
> > format of the dtrace-generated probes.o is documented someplace?
>
> I have heard that dtrace does work a bit differently on macos but I
> would need to investigate. The probes.o file is different for systemtap
> and dtrace. For systemtap it is simply an objectfile with variable
> definitions for the probe semaphores (to test if a probe is enabled;
> mostly used by interpreters like java). For dtrace, hmm been a while
> since I looked at it. dtrace uses an interpreter that runs in the
> kernel, I think probes.o contains the bytecodes for the probes.
Thanks for the info. I'll try out a Mac build soon & see how it
fares (mostly just want to be sure that it continues to build at
this stage, else we'll have accidentally regressed there).
> > Shouldn't the build just continue on without dtrace configured in?
>
> The model I followed, mysql/postgres work this way but I did make the
> failure fatal.
OK, I've noticed a few small issues with the configure-y, made a
few changes there today on top of what we discussed on IRC (please
review if you get a chance - thanks!).
> > All of this decoding should be offloaded to the event handler,
>
> trace.c is now much simpler. The trace display logic is now moved to
> pmcd.std, the systemtap probe handler.
>
> > Do we really need it, given its in the !dtrace path?
>
> This is now eliminated in favor of having configure create config.h
> which indicates the presence or absence of --enable-dtrace.
That header dup'd another with similar reason-for-living - I ended
up merging the two (I preferred your new name, so stuck with that).
> > could you update the RPM build dependencies in the
> > build/rpm spec files as well?
>
> Still need to do this.
This is done now, and its all merged and QA appears all good. As we
discussed on IRC, a simple test to exercise that probes can be found
would be great. I also added a "pmconfig -L" line that should prove
handy for testing - see some of the other tests that use pmconfig
(test qa/943 is a good example, does the _notrun check for any build
without needed features).
One final suggestion - it occurred to me while looking over pmcd_probe
once more that the existing tracing had a split between pdu vs non-pdu
trace traffic. It would possibly be easy to maintain that in these
probes, such that one can choose to (eg) not wear the pdu traffic trace
cost, just the other lower-volume tracing. Something along the lines
of:
diff --git a/src/libpcp_pmcd/src/trace.c b/src/libpcp_pmcd/src/trace.c
index 125b717..3e434ba 100644
--- a/src/libpcp_pmcd/src/trace.c
+++ b/src/libpcp_pmcd/src/trace.c
@@ -74,14 +74,14 @@ pmcd_trace(int type, int who, int p1, int p2)
{
int p;
- PROBE_PMCD(type, who, p1, p2);
-
switch (type) {
case TR_XMIT_PDU:
case TR_RECV_PDU:
+ PROBE_PMCD_PDU(type, who, p1, p2);
if ((_pmcd_trace_mask & TR_MASK_PDU) == 0)
return;
default:
+ PROBE_PMCD(type, who, p1, p2);
if ((_pmcd_trace_mask & TR_MASK_CONN) == 0)
return;
}
... obviously a bit more to it than just that, but does that seem like
a useful addition?
cheers.
--
Nathan
|