|
|
udi_trace_write(3udi)
Record trace data
#include <udi.h>void udi_trace_write ( udi_init_context_t *init_context, udi_trevent_t trace_event, udi_index_t meta_idx, udi_ubit32_t msgnum, ... );ARGUMENTS init_context is a pointer to the front of the driver's region data area and is used to uniquely identify this driver instance.
trace_event is the type of trace event being reported.
meta_idx is a metalanguage index number that identifies the metalanguage to which trace_event is relative, for metalanguage-selectable trace events. It must match the value of <meta_idx> in the corresponding "child_meta", "parent_meta", or "internal_meta" declaration of the driver's Static Driver Properties (see Chapter 30), or 0 for the Management Metalanguage. If the event is not metalanguage-selectable, meta_idx is ignored.
msgnum is the index value of a message string provided in the driver's static properties file (see Section 30.4.9, "Message Declaration"). This selects the text of the message to be traced. Any embedded formatting codes in the text of that message will be used to format the traced message with the remaining arguments supplied to this call. The formatting is performed as if the message string and remaining arguments were passed to the udi_snprintf utility function (see udi_snprintf).
... are the remaining arguments which provide the values used for the formatting codes contained in the message identified by msgnum. Arguments formatted with %c or %s format codes must not contain newline (`\n') or other control characters.
DESCRIPTION This routine traces data generated by the driver. Time-stamping of trace entries will be done at the discretion of the environment; the driver is not expected to supply timestamp information.
To simplify usage, udi_trace_write does not involve a callback. The environment will immediately copy the msgnum and remaining arguments into its own buffers for immediate or delayed processing. This may result in loss of trace data during unusually heavy usage. The driver writer is encouraged to keep trace entries short to minimize this possibility.
If the driver wishes to log and trace the same event, the udi_log_write operation should be used instead.