interface xdc.runtime.ILogger

Interface to service Log events

A logger is responsible for recording, transmitting, or otherwise handling Log Events generated by clients of the Log module. The Log module uses modules that implement the ILogger interface to record the log events. Most application code will use the Log module instead of directly calling the specific ILogger module implementation. [ more ... ]
XDCspec summary sourced in xdc/runtime/ILogger.xdc
interface ILogger {  ...
// inherits xdc.runtime.IModule
instance:  ...
XDCspec declarations sourced in xdc/runtime/ILogger.xdc
package xdc.runtime;
 
interface ILogger {
module-wide config parameters
module-wide functions
 
 
instance:
per-instance functions
    Bool disable// Disable a log();
    Bool enable// Enable a log();
    Void write2// Process a log event with 2 arguments(Log.Event evt, Types.ModuleId mid, IArg a1, IArg a2);
    Void write4// Process a log event with up to 4 arguments(Log.Event evt, Types.ModuleId mid, IArg a1, IArg a2, IArg a3, IArg a4);
    Void write8// Process a log event with up to 8 arguments(Log.Event evt, Types.ModuleId mid, IArg a1, IArg a2, IArg a3, IArg a4, IArg a5, IArg a6, IArg a7, IArg a8);
}
DETAILS
A logger is responsible for recording, transmitting, or otherwise handling Log Events generated by clients of the Log module. The Log module uses modules that implement the ILogger interface to record the log events. Most application code will use the Log module instead of directly calling the specific ILogger module implementation.
All logger implementations must inherit from this interface. The derived implementations must implement the functions defined in this interface but may also add additional configuration parameters and functions.
Events may be defined with a detail level, but the Log interface does not inherently provide support for filtering of events based on detail level. Instead, this is left to the ILogger implementation. ILogger implementations which wish to support filtering based on detail level should implement the IFilterLogger interface, which extends the ILogger interface to include APIs for getting and setting the current filter level.
 
metaonly config ILogger.common$  // module-wide

Common module configuration parameters

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
metaonly config Types.Common$ common$;
 
DETAILS
All modules have this configuration parameter. Its name contains the '$' character to ensure it does not conflict with configuration parameters declared by the module. This allows new configuration parameters to be added in the future without any chance of breaking existing modules.
 
metaonly ILogger.getMetaArgs()  // module-wide

Returns any meta data needed to support RTA

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
metaonly function getMetaArgs(inst, instNum);
 
DETAILS
This meta data should be returned in the form of a structure which can be converted into XML. This data is added to the RTA XML file during the application's configuration, and can be accessed later through the xdc.rta.MetaData module.
The MetaData is returned per instance of the ILogger module. The instance object is passed to the function as the first argument.
The second argument is the index of the instance in the list of the ILogger's static instances.
 
ILogger.disable()  // instance

Disable a log

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Bool disable();
 
DETAILS
Events written to a disabled log are silently discarded.
RETURNS
The function returns the state of the log (TRUE if enabled, FALSE if disabled) before the call. This return value allows clients to restore the previous state. Note: not thread safe.
 
ILogger.enable()  // instance

Enable a log

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Bool enable();
 
RETURNS
The function returns the state of the log (TRUE if enabled, FALSE if disabled) before the call. This return value allows clients to restore the previous state. Note: not thread safe.
 
ILogger.write0()  // instance

Process a log event with 0 arguments

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Void write0(Log.Event evt, Types.ModuleId mid);
 
DETAILS
Same as write4 except with 0 arguments rather than 4.
SEE
 
ILogger.write1()  // instance

Process a log event with 1 arguments

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Void write1(Log.Event evt, Types.ModuleId mid, IArg a1);
 
DETAILS
Same as write4 except with 1 arguments rather than 4.
SEE
 
ILogger.write2()  // instance

Process a log event with 2 arguments

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Void write2(Log.Event evt, Types.ModuleId mid, IArg a1, IArg a2);
 
DETAILS
Same as write4 except with 2 arguments rather than 4.
SEE
 
ILogger.write4()  // instance

Process a log event with up to 4 arguments

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Void write4(Log.Event evt, Types.ModuleId mid, IArg a1, IArg a2, IArg a3, IArg a4);
 
ARGUMENTS
evt — event to be logged
mid — module ID of the module which logged the event
a1 — arbitrary argument passed by caller
DETAILS
The evt argument is of type Log.Event, which encodes the Log.EventId, the Diags.Mask, and the Diags.EventLevel of the event. The event ID can be obtained via Types.getEventId(evt), the Diags mask can be obtained via Diags.getMask(evt), and the event level can be obtained via Diags.getLevel(evt).
The modId argument is the module ID of the module that logged the event.
The event information can be used by the logger to handle different events specially. For example, the event ID can be used to compare against other known Log.Events.
      if (Log_getEventId(MY_EVENT) == Log_getEventId(evt)) {
          :
      }
The Diags mask and event level can be used for filtering of events based on event level (see IFilterLogger), or even routing events to separate loggers based on diags category (see, for example, LoggerBuf.statusLogger).
The Diags mask and event level are useful for handling the event, but are generally not recorded by the logger because they are not needed in decoding and displaying the event. A more suitable value to record is a Types.Event, which encodes the event ID and module ID. For example, the Log.EventRec type stores a Types.Event in its record definition. A Types.Event can be created using the Types.makeEvent API given the event ID and module ID.
The event ID value of 0 is used to indicate an event triggered by a call to one of the Log_print[0-6] methods. These methods take a format string rather than a Log_Event argument and, as a result, the event ID encoded in evt is 0 and the parameter a1 is the format string.
Non-zero event IDs can also be used to access the msg string associated with the Log.EventDesc that originally defined the Log event.
      Log_EventId id = Log_getEventId(evt));
      if (id != 0) {
          String msg = Text_ropeText(id);
          System_aprintf(msg, a1, a2, a3, a4);
      }
This works because an event's ID is simply an offset into a table of characters (maintained by the Text module) containing the event's msg string.
The arguments a1, a2, etc. are parameters that are to be interpreted according to the message format string associated with evt.
SEE
 
ILogger.write8()  // instance

Process a log event with up to 8 arguments

XDCspec declarations sourced in xdc/runtime/ILogger.xdc
Void write8(Log.Event evt, Types.ModuleId mid, IArg a1, IArg a2, IArg a3, IArg a4, IArg a5, IArg a6, IArg a7, IArg a8);
 
DETAILS
Same as write4 except with 8 arguments rather than 4.
SEE
generated on Thu, 25 May 2017 22:12:12 GMT