Hi Dave,
I've managed to lose your last mail on this topic, so these
notes are just free-form as I read through the code in your
current pcpfans nss branch.
Overall its looking like its progressing along nicely. I'd
like to start getting some of the "wrapper" style changes
(API level) merged soonish (pcp-3.6.7), as they stand alone
and can go in anytime. This might help to break up the work
into smaller chunks, rather than us having a single whopping
big commit arrive down the track. I'll start trying to help
out on that next week.
== 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?
- 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.
- pmio.h -> impl.h &| platform_defs.h? (prefer no new header)
- auxconnect.c
-> hmm, this seems to create a second file descriptor
table? I was expecting this code to all be over
in ipc.c in libpcp, and augmenting the existing
table there rather than dup'ing it. Means we're
doubling up on memory allocation calls, PM_LOCK/
PM_UNLOCK calls, etc for every socket we create?
-> checking back on Kens mail, yeah - he said the
same thing... was there a reason this approach
didn't pan out?
| What I had in mind was something along these lines:
|
| * change the __pmIPC structure as follows:
| * change socket to be flags and define bit field flags to
| encode the channel's type (socket or otherwise for
| Windows), clear text or encrypted (for your use), etc.
| * add an int fd field for the clear text case
| * add whatever extra "stuff" you need to make encrypted
| I/O work
- __pmSelectRead? not __pmSelect? (shrug, just stood out)
- 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)
Will talk more next week - I'm away for the weekend shortly,
and wont be checking mail for a coupla days.
cheers.
--
Nathan
|