HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. |  |
NAME |C SYNOPSIS |DESCRIPTION |CALLBACKS |DIAGNOSTICS |SEE ALSO |COLOPHON | |
PMDAMAIN(3) Library Functions ManualPMDAMAIN(3)pmdaMain,pmdaGetContext,pmdaSetResultCallBack,pmdaSetCheckCallBack,pmdaSetDoneCallBack,pmdaSetEndContextCallBack- generic PDU processing for a PMDA
#include <pcp/pmapi.h>#include <pcp/pmda.h>void pmdaMain(pmdaInterface *dispatch);void pmdaSetCheckCallBack(pmdaInterface *dispatch,pmdaCheckCallBackcallback);void pmdaSetDoneCallBack(pmdaInterface *dispatch,pmdaDoneCallBackcallback);void pmdaSetResultCallBack(pmdaInterface *dispatch,pmdaResultCallBackcallback);void pmdaSetEndContextCallBack(pmdaInterface *dispatch,pmdaEndContextCallBackcallback);int pmdaGetContext(void);cc ... -lpcp_pmda -lpcp
For Performance Metric Domain Agents (PMDA(3)) using the binary PDU protocols to communicate withpmcd(1), the routinepmdaMain provides a generic implementation of the PDU-driven main loop.dispatch describes how to process each incoming PDU. It is a vec‐ tor 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 in‐ terface versions that have evolved over time. ForpmdaMain,dis‐patch->domain anddispatch->status are ignored. Thecomm.pmda_in‐terface field is used to determine the interface used by the PMDA. Setting this field toPMDA_INTERFACE_2orPMDA_INTERFACE_3will forcepmdaMainto use the callbacks in theversion.two orver‐sion.three structure. A setting ofPMDA_INTERFACE_4orPMDA_IN‐TERFACE_5will forcepmdaMainto use the callbacks in thever‐sion.four orversion.five structure, and similarly aPMDA_INTER‐FACE_6setting forcespmdaMainto use the callbacks in thever‐sion.six structure. Any other value will result in an error and termination ofpmdaMain. Note that the use ofdispatchas the interface between thepmcd(1) and the methods of the PMDA allows each PMDA to be implemented as though it were a DSO, withpmdaMainproviding a convenient wrapper that may be used to convert from the DSO interface to the binary PDU (daemon PMDA) interface.pmdaMainexecutes as a continuous loop, returning only when an end of file is encountered on the PDU input file descriptor.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), andpmdaAttribute(3) there are other callbacks that can affect or inform all PDU processing within a PMDA, namelycheck,done andend. These callbacks should be set withpm‐daSetCheckCallBack,pmdaSetDoneCallBackandpmdaSetEndContextCall‐Back. If not null,check is called after each PDU is received (but be‐ fore it was processed), anddone is called after each PDU is sent. Ifcheck 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 topmcd(1) - this may be used for PM‐ DAs that require some sort of deferred connection or reconnect protocols for the underlying sources of performance metrics, e.g. a DBMS. The error indication fromcheck is not passed back topmcd(1) in the cases where no acknowledgment is expected, e.g. for a PDU_PROFILE. Theend callback allows a PMDA to keep track of state for individ‐ ual clients that are requesting it to perform actions (PDU pro‐ cessing). UsingpmdaGetContexta 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 han‐ dling event metrics, where each event must be propagated once only to each interested client. It also underlies the mechanism where‐ by 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 thepmResult built for a PDU_RESULT in response to a PDU_FETCH request. By de‐ fault,pmdaMainwill free thepmResultonce the result has been sent to thepmcd(1). For some PMDAs this is inappropriate, e.g. thepmResultis statically allocated, or contains a hybrid of pinned PDU buffer information and dynamically allocated informa‐ tion.pmdaSetResultCallBackmay be used to define an alternativecallbackfrompmdaMain.
These messages may be appended to the PMDA's log file:PMDA interface versioninterfacenot supported Theinterface version is not supported bypmdaMain.Unrecognized pdu type The PMDA received a PDU frompmcdthat it does not recog‐ nize. This may indicate that thepmcdprocess is using a more advanced interface thanpmdaMain. If thePMAPI(3) debugging control options have the ``libpmda'' op‐ tion set then each PDU that is received is reported in the PMDA's log file.
pmcd(1),PMAPI(3),PMDA(3),pmdaProfile(3),pmdaFetch(3),pmdaDesc(3),pmdaInstance(3),pmdaText(3),pmdaStore(3),pmdaPMID(3),pmdaName(3),pmdaChildren(3), andpmdaAttribute(3).
This page is part of thePCP (Performance Co-Pilot) project. In‐ formation 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@groups.io. This page was obtained from the project's upstream Git repository ⟨https://github.com/performancecopilot/pcp.git⟩ on 2025-08-11. (At that time, the date of the most recent commit that was found in the repository was 2025-08-11.) 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 isnot part of the original manual page), send a mail to man-pages@man7.orgPerformance Co-Pilot PCPPMDAMAIN(3)Pages that refer to this page:pmda(3), pmdaattribute(3), pmdachildren(3), pmdaeventclient(3), pmdaname(3), pmdapmid(3)
HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. | |