1. Allow easy parameters management in oai, helping the development of a flexible, modularized and fully configurable softmodem.
1. Use a common configuration API in all oai modules
1. Allow development of alternative configuration sources without modifying the oai code. Today the only delivered configuration source is the libconfig format configuration file.
The loader objectives are
1. provides a common mechanism to prevent an executable to include code that is only used under specific configurations, without rebuilding the code
1. Provide a common mechanism to allow to choose between different implementations of a given set of functions, without rebuilding the code
As a developer you may need to look at these sections:
The oai logging facility is implemented in two source files, located in [common/utils](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils)
1.[log.h](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/log.h) is the logging facility include file containing both private and public data type definitions. It also contain API prototypes.
1. Allow a flexible activation of console traces, by configuration or dynamically at any time while code is running.
Once the logging facility has been initialized and configured developpers use C preprocessor macros to include console messages in their code. At execution time, these traces will be printed or not to the console depending on the configuration, as described [here](rtusage.md). The logging facility also defines preprocessor macros to include condtional code, to dump memory blocks (buffers, messages...).
All macros are defined in [log.h](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/LOG/log.h) include file, which must be included in any source file using the logging facility macros.
[log.h](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/LOG/log.h) also includes the prototypes of the functions that have to be called to initialize, configure or get the status of console logs.
#### console messages macros
```C
LOG_E(<component>,<format>,<argument>,...)
LOG_W(<component>,<format>,<argument>,...)
LOG_I(<component>,<format>,<argument>,...)
LOG_D(<component>,<format>,<argument>,...)
LOG_T(<component>,<format>,<argument>,...)
)
```
these macros are used in place of the printf C function. The additionnal ***component*** parameter identifies the functionnal module which generates the message. At run time, the message will only be printed if the configured log level for the component is greater or equal than the macro level used in the code.
| macro | level letter | level value | level name |
component list is defined as an `enum` in [log.h](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/LOG/log.h). A new component can be defined by adding an item in this type, it must also be defined in the T tracer [T_messages.txt ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/T/T_messages.txt).
Most oai sources are including LOG macros.
#### conditional code macros
```C
LOG_DEBUGFLAG(<flag>)
```
this macro is to be used in if statements. The condition is true if the flag has been set, as described in the [run time usage page](rtusage.md)
```C
if ( LOG_DEBUGFLAG(<flag>) {
/*
the code below is only executed if the corresponding
<flag>_debug option is set.
*/
......................
......................
}
```
[example in oai code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/PHY/LTE_TRANSPORT/ulsch_demodulation.c#L396)
#### memory dump macros
```C
LOG_DUMPFLAG(<flag>)
```
this macro is to be used in if statements. The condition is true if the flag has been set, as described in the [run time usage page](rtusage.md). It is mainly provided to surround LOG_M macros or direct calls to `log_dump`which otherwise would be unconditionals.
```C
if ( LOG_DUMPFLAG(<flag>) {
/*
the code below is only executed if the corresponding
<flag>_dump option is set.
*/
LOG_M(.............
LOG_M(.............
log_dump(...
}
[example in oai code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/PHY/LTE_TRANSPORT/prach.c#L205)
#### matlab format dump
```C
LOG_M(file, vector, data, len, dec, format)
```
|argument| type| description |
|:-----------|:-------|-----------------:|
| file | char* |path to the fle which will contain the dump |
|vector |char * |name of the dump, printed at the top of the dump file |
|data| void *| pointer to the memory to be dumpped |
|len | int | length of the data to be dumpped, in `dec` unit|
| dec| int | length of each data item.Interpretation depends on format|
|format| int | defines the type of data to be dumped|
This macro can be used to dump a buffer in a format that can be used for analyze via tools like matlab or octave. **It must be surrounded by LOG_DEBUGFLAG or LOG_DUMPFLAG macros, to prevent the dump to be built unconditionally.** The LOG_M macro points to the `write_file_matlab` function implemented in [log.c](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/LOG/log.c). **This function should be revisited for more understandable implementation and ease of use (format parameter ???)**
[example in oai code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/PHY/LTE_TRANSPORT/prach.c#L205)
#### hexadecimal format dump
```C
LOG_DUMPMSG(c, f, b, s, x...)
```
dumps a memory region if the corresponding debug flag `f` is set as explained here [run time usage page](rtusage.md)
|argument| type| description |
|:-----------|:-------|-----------------:|
| c | int, component id (in `comp_name_t` enum)| used to print the message, as specified by the s and x arguments |
|f |int |flag used to filter the dump depending on the logs configuration. flag list is defined by the LOG_MASKMAP_INIT macro in [log.h](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/LOG/log.h) |
|b| void *| pointer to the memory to be dumpped |
|s | int | length of the data to be dumpped in char|
| x...| printf format and arguments| text string to be printed at the top of the dump|
This macro can be used to conditionaly dump a buffer, bytes by bytes, giving the integer value of each byte in hexadecimal form.
[example in oai code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/RRC/LTE/rrc_eNB.c#L1181)
This macro points to the `log_dump` function, implemented in [log.c](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/LOG/log.c). This function can also dump buffers containing `double` data via the LOG_UDUMPMSG macro
```C
LOG_UDUMPMSG(c, b, s, f, x...)
```
|argument| type| description |
|:-----------|:-------|-----------------:|
| c | int, component id (in `comp_name_t` enum)| used to print the message, as specified by the s and x arguments |
|b| void *| pointer to the memory to be dumpped |
|s | int | length of the data to be dumpped in char|
|f| int | format of dumped data LOG_DUMP_CHAR or LOG_DUMP_DOUBLE|
| x...| printf format and arguments| text string to be printed at the top of the dump|
[example in oai code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/SIMULATION/LTE_PHY/dlsim.c#L1974)
oai includes a console logging facility that any component should use when writting informational or debugging messages to the softmodem or uesoftmodem stdout stream.
By default, this facility is included at build-time and activated at run-time. The T Tracer and the Logging facility share common options for activation:
- To disable the logging facility (and T Tracer) at build-time use the *--disable-T-Tracer* switch:
```bash
/build_oai --disable-T-Tracer
```
- To use the the T-Tracer instead of the console logging facility, use the command line option *T_stdout*. *T_stdout* is a boolean option, which, when set to 0 (false) disable the console logging facility. All stdout messages are then sent to the T-Tracer.
