Hey Dave,
Firstly, forgot to mention last time - you might find this work
will be aided by the wireshark PCP dissector (the credentials
exchange, especially). Not sure if that is in any released
version of wireshark yet, but it was merged into the wireshark
source tree earlier in the year.
----- Original Message -----
> On 08/23/2012 11:39 PM, Nathan Scott wrote:
> > ...
> > big commit arrive down the track. I'll start trying to help
> > out on that next week.
> Thanks. Yes. I feel like this branch is getting old and crusty. I
> would
> like to run the entire testsuite against the current dev branch and
> then
> with my changes for NSS/NSPR enabled and disabled, all with the same
> results before we push it.
*nod* - good plan re doing that testing. Since there's a bit of
rework required around the ipc table, I was thinking of pulling
out just the api-wrapper type changes (so, a no-op change) and
testing/merging those (by hand, probably, not git merge on the
nss branch, which is starting to look a bit like its done a few
rounds with Mike Tyson).
Then I think it would be worth resetting the clock, and pick out
the remaining pieces one at a time, and re-commit those that will
stay with us long-term. I'd be happy to go through and extract
the API wrapping bits, if you don't mind this approach? (I would
imagine a new branch would be worthwhile for the next iteration
after that, perhaps a brolley/nss2, cos it will likely be a merge
nightmare after the wrapper api extraction). Hmm, that is all
sounding a bit hairy - lets discuss by phone tomorrow?
> > == NSS/NSPR notes
> >
> > - configure.in: explicit require on fedora/redhat... hmmm?
> > this would mean cannot monitor a RHEL server from, say, a
> > Mac OS X pmchart? are their known issues with the other
> > platforms that require this check?
> Any requirement placed on RHEL or Fedora is purely temporary. I'm
> just
> not expert enough to know whether the particular test framework that
> used (stolen from systemtap) is portable. Any assistance is
> appreciated!
The configure.in snippet from systemtap for NSS looks a fair bit
simpler than what's currently in this branch ... go with that I'd
say (no mention of fedora/rhel in systemtap master branch).
> > - LogImport/Makefile.PL ... this change seems unnecessary?
> > (logimport is all about archives, not live monitoring)
> >
> > Ohhh... this is part of a bigger linkage issue:
> > Will all out-of-tree pcp client tools will have unresolved
> > NSS symbols on the next pcp upgrade? ... that would be bad.
> > Isn't there a way to link one shared library with another?
> > Ideally, there is and we'd link libpcp that way. Otherwise
> > this is going to be very intrusive for the punters.
> Agreed and, once again, not intended. Also, once again, any
> assistance is appreciated.
We'll need to ponder/investigate this further. Worst case scenario
we can dlopen the nss library from within libpcp and access it that
way, but I have a vague memory of better linkage options than that.
[ /me returns from pondering ... oh, its easily done - we already do
it in fact, for -lpthread -lm and -ldl. We need to extend LLDLIBS
in libpcp/src/GNUmakefile with a $(LIB_FOR_NSS) - which configure is
going to fill in for us, ultimately. gcc magic then does the rest. ]
> you've outlined above. I decided not to play with such a vital table
> right away.
Fair enough.
> Now that the basic work is done, it does seem like it
> would be easy to integrate.
OK, good stuff.
> > - __pmSelectRead? not __pmSelect? (shrug, just stood out)
> Yeah. I noticed that nowhere in pcp does both at once and the
> abstraction worked out pretty easily if one or the other was assumed.
> A general implementation could still be done if you like.
Was more just the name that caught my eye - everything else was
more of a direct translation, whereas this one acquired a "Read"
suffix seemingly out of the blue.
> > - linux/pmda.c - ugh! in hind-sight, surprising we've not
> > come across this before. Might be something we should be
> > doing better in PCP (I'll have a look, see if this becomes
> > a big change, if not will rename domain definitions to be
> > more unique - PCP_LINUX_DOMAIN, for example)
> Seems like a NSS/NSPR namespace violation to me, but yes.....ugh!
Yeah, could argue it both ways - I tried out changing some of the
domain numbers over to PMDA_LINUX, PMDA_PMCD ... with no ill effect,
keen to hear from some of the other old-timer PCP folk as to whether
they can think of potential issues there though? (anyone? Max/Mark/
Ken...?) Perhaps PMD_LINUX would make more sense, since its not so
much an Agent thing, as a Domain thing?
cheers.
--
Nathan
|