Hi Mark,
----- Original Message -----
> On 09/05/2014 08:15 PM, Nathan Scott wrote:
> > [ ... ]
> > 2. Many PMDAs (including "core" PMDAs) have both daemon & DSO
> > variants which duplicate a bit of code (hence increasing the
> > installed package size ondisk). I wonder if we could move to
> > a model where the daemon PMDAs in such cases use the run-time
> > DSO, instead of linking with the .o at build time? (this'll
> > need a new libpcp_pmda helper function to wrap the dlopen(3)
> > call).
>
> That could work. Another idea could be to only ship the DSO
> variant for some PMDAs, which would be preferable to shipping
> only the daemon - for local context support.
*nod* - in the past, the other advantage of having daemon is you
can isolate PMDA performance analysis to the individual process
(pmdalinux has been beaten with this stick a number of times).
> We could add a new PMDA_INTERFACE version that supports e.g.
> FOO_args(argc, argv) or perhaps an extended FOO_init() that has
> support for args, something like that. PMDAs that need arguments
Yep, interesting approach - that'd tackle a DSO PMDA limitation
in the process - bonus.
> (such as the logger PMDA) could then be DSOs, which would be a
> step closer to a viable pmlogger that only uses a local context
> (no pmcd required for a minimal logging deployment).
Yeah. Hey - on that, I was thinking about revving the pmlogger
control file format recently to help out local-context-pmlogger
for the case where DSO PMDAs need to run as root. We currently
have a pmsocks column, bit-rotting away nicely - maybe we could
reclaim that (v1.2 format) and make it mean "run pmlogger under
sudo" instead?
cheers.
--
Nathan
|