NAME | C SYNOPSIS | DESCRIPTION | CALLBACKS | DIAGNOSTICS | SEE ALSO | COLOPHON

PMDAMAIN(3)               Library Functions Manual               PMDAMAIN(3)

NAME         top

       pmdaMain,  pmdaGetContext,  pmdaSetResultCallBack,  pmdaSetCheckCall‐
       Back, pmdaSetDoneCallBack, pmdaSetEndContextCallBack  -  generic  PDU
       processing for a PMDA

C SYNOPSIS         top

       #include <pcp/pmapi.h>
       #include <pcp/impl.h>
       #include <pcp/pmda.h>
       cc ... -lpcp_pmda -lpcp
       void pmdaMain(pmdaInterface *dispatch);
       void pmdaSetCheckCallBack(pmdaInterface *dispatch,
               pmdaCheckCallBack callback);
       void pmdaSetDoneCallBack(pmdaInterface *dispatch,
               pmdaDoneCallBack callback);
       void pmdaSetResultCallBack(pmdaInterface *dispatch,
               pmdaResultCallBack callback);
       void pmdaSetEndContextCallBack(pmdaInterface *dispatch,
               pmdaEndContextCallBack callback);
       int pmdaGetContext(void);

DESCRIPTION         top

       For Performance Metric Domain Agents (PMDA(3)) using the binary PDU
       protocols to communicate with pmcd(1), the routine pmdaMain provides
       a generic implementation of the PDU-driven main loop.
       dispatch describes how to process each incoming PDU. It is a vector
       of function pointers, one per request PDU type, as used in the DSO
       interface for a PMDA, namely:
       /*
        * Interface Definitions for PMDA Methods
        */
       typedef struct {
           int domain;         /* set/return performance metrics domain id here */
           struct {
               unsigned int    pmda_interface: 8; /* PMDA DSO interface version */
               unsigned int    pmapi_version : 8; /* PMAPI version */
               unsigned int    flags : 16;        /* optional feature flags */
           } comm;             /* set/return communication and version info */
           int status;         /* return initialization status here */
           union {
               struct {                              /* PMDA_INTERFACE_2 or _3 */
                   pmdaExt *ext;
                   int (*profile)(__pmProfile *, pmdaExt *);
                   int (*fetch)(int, pmID *, pmResult **, pmdaExt *);
                   int (*desc)(pmID, pmDesc *, pmdaExt *);
                   int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *);
                   int (*text)(int, int, char **, pmdaExt *);
                   int (*store)(pmResult *, pmdaExt *);
               } two, three;
               struct {                              /* PMDA_INTERFACE_4 or _5 */
                   pmdaExt *ext;
                   int     (*profile)(__pmProfile *, pmdaExt *);
                   int     (*fetch)(int, pmID *, pmResult **, pmdaExt *);
                   int     (*desc)(pmID, pmDesc *, pmdaExt *);
                   int     (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *);
                   int     (*text)(int, int, char **, pmdaExt *);
                   int     (*store)(pmResult *, pmdaExt *);
                   int     (*pmid)(char *, pmID *, pmdaExt *);
                   int     (*name)(pmID, char ***, pmdaExt *);
                   int     (*children)(char *, int, char ***, int **, pmdaExt *);
               } four, five;
               struct {                              /* PMDA_INTERFACE_6 */
                   pmdaExt *ext;
                   int     (*profile)(__pmProfile *, pmdaExt *);
                   int     (*fetch)(int, pmID *, pmResult **, pmdaExt *);
                   int     (*desc)(pmID, pmDesc *, pmdaExt *);
                   int     (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *);
                   int     (*text)(int, int, char **, pmdaExt *);
                   int     (*store)(pmResult *, pmdaExt *);
                   int     (*pmid)(char *, pmID *, pmdaExt *);
                   int     (*name)(pmID, char ***, pmdaExt *);
                   int     (*children)(char *, int, char ***, int **, pmdaExt *);
                   int     (*attribute)(int, int, const char *, int, pmdaExt *);
               } six;
           } version;
       } pmdaInterface;
       This structure has been extended to incorporate the multiple
       interface versions that have evolved over time.  For pmdaMain,
       dispatch->domain and dispatch->status are ignored.  The
       comm.pmda_interface field is used to determine the interface used by
       the PMDA.  Setting this field to PMDA_INTERFACE_2 or PMDA_INTERFACE_3
       will force pmdaMain to use the callbacks in the version.two or
       version.three structure.  A setting of PMDA_INTERFACE_4 or
       PMDA_INTERFACE_5 will force pmdaMain to use the callbacks in the
       version.four or version.five structure, and similarly a
       PMDA_INTERFACE_6 setting forces pmdaMain to use the callbacks in the
       version.six structure.  Any other value will result in an error and
       termination of pmdaMain.
       Note that the use of dispatch as the interface between the pmcd(1)
       and the methods of the PMDA allows each PMDA to be implemented as
       though it were a DSO, with pmdaMain providing a convenient wrapper
       that may be used to convert from the DSO interface to the binary PDU
       (daemon PMDA) interface.
       pmdaMain executes as a continuous loop, returning only when an end of
       file is encountered on the PDU input file descriptor.

CALLBACKS         top

       In addition to the individual PDU processing callbacks -
       pmdaProfile(3), pmdaFetch(3), pmdaDesc(3), pmdaInstance(3),
       pmdaText(3), pmdaStore(3), pmdaPMID(3), pmdaName(3), pmdaChildren(3),
       and pmdaAttribute(3) there are other callbacks that can affect or
       inform all PDU processing within a PMDA, namely check, done and end.
       These callbacks should be set with pmdaSetCheckCallBack,
       pmdaSetDoneCallBack and pmdaSetEndContextCallBack.
       If not null, check is called after each PDU is received (but before
       it was processed), and done is called after each PDU is sent.  If
       check returns a value less than zero (typically PM_ERR_AGAIN), the
       PDU processing is skipped and in most cases the function value is
       returned as an error PDU to pmcd(1) - this may be used for PMDAs that
       require some sort of deferred connection or reconnect protocols for
       the underlying sources of performance metrics, e.g. a DBMS.  The
       error indication from check is not passed back to pmcd(1) in the
       cases where no acknowledgment is expected, e.g. for a PDU_PROFILE.
       The end callback allows a PMDA to keep track of state for individual
       clients that are requesting it to perform actions (PDU processing).
       Using pmdaGetContext a PMDA can determine, at any point, an integer
       identifier that uniquely identifies the client tools at the remote
       end of PMCD (for local context modes, this identifier is always
       zero).  This becomes very important for handling event metrics, where
       each event must be propagated once only to each interested client.
       It also underlies the mechanism whereby connection information is
       passed to the PMDA, such as the the credentials (user and group
       identifiers) for the client tool.
       One final callback mechanism is provided for handling the pmResult
       built for a PDU_RESULT in response to a PDU_FETCH request.  By
       default, pmdaMain will free the pmResult once the result has been
       sent to the pmcd(1).  For some PMDAs this is inappropriate, e.g. the
       pmResult is statically allocated, or contains a hybrid of pinned PDU
       buffer information and dynamically allocated information.
       pmdaSetResultCallback may be used to define an alternative callback
       from pmdaMain.

DIAGNOSTICS         top

       These messages may be appended to the PMDA's log file:
       PMDA interface version interface not supported
                                The interface version is not supported by
                                pmdaMain.
       Unrecognized pdu type    The PMDA received a PDU from pmcd that it
                                does not recognize. This may indicate that
                                the pmcd process is using a more advanced
                                interface than pmdaMain.
       If the PMAPI(3) debug control variable (pmdebug) has the
       DBG_TRACE_LIBPMDA flag set then each PDU that is received is reported
       in the PMDA's log file.

SEE ALSO         top

       pmcd(1), PMAPI(3), PMDA(3), pmdaProfile(3), pmdaFetch(3),
       pmdaDesc(3), pmdaInstance(3), pmdaText(3), pmdaStore(3), pmdaPMID(3),
       pmdaName(3), pmdaChildren(3), and pmdaAttribute(3).

COLOPHON         top

       This page is part of the PCP (Performance Co-Pilot) project.
       Information about the project can be found at ⟨http://www.pcp.io/⟩.
       If you have a bug report for this manual page, send it to
       pcp@oss.sgi.com.  This page was obtained from the project's upstream
       Git repository ⟨git://git.pcp.io/pcp⟩ on 2017-07-05.  If you discover
       any rendering problems in this HTML version of the page, or you
       believe there is a better or more up-to-date source for the page, or
       you have corrections or improvements to the information in this
       COLOPHON (which is not part of the original manual page), send a mail
       to man-pages@man7.org
Performance Co-Pilot                 PCP                         PMDAMAIN(3)

Pages that refer to this page: pmda(3)pmdaattribute(3)pmdachildren(3)pmdaeventclient(3)pmdaname(3)pmdapmid(3)