Commit c1f7678e authored by Raphael Defosseux's avatar Raphael Defosseux

Merge branch 'develop_integration_2018_w46' into 'develop'

Develop integration 2018 w46

See merge request !445
parents d00f80b5 18a099fa
Pipeline #10987 failed with stage
in 0 seconds
# OAI configuration module
The configuration module provides an api that other oai components can use to get parameters at init time. It defines a parameter structure, used to describe parameters attributes (for example name and type). The same structure includes a pointer to the variable where the configuration module writes the parameter value, at run time, when calling config_get or config_getlist functions. For each parameter a function to check the value can be specified and pre-defined functions are provided for some common parameter validations (integer in a range or in a list, string in a list). The module also include a mechanism to check that no unknown options have been entered on the command line
## Documentation
* [runtime usage](config/rtusage.md)
* [developer usage](config/devusage.md)
* [module architecture](config/arch.md)
[oai Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
# config module source files
![configmodule_srcdir](/uploads/fdc3e96011fd5592440900dfa05b4701/configmodule_srcdir.png)
# config module components
![configmodule_components](/uploads/54f8a3953d5ee53717cd9a3b71f85c68/configmodule_components.png)
[Configuration module home](../config.md)
\ No newline at end of file
The configuration module objectives are
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.
As a developer you may need to look at these sections:
* [add parameters in an existing section](devusage/addaparam.md)
* [add a parameter set, in a new section](devusage/addparamset.md)
* [configuration module API](devusage/api.md)
* [configuration module public structures](devusage/struct.md)
Whatever your need is, configuration module usage examples can be found in oai sources:
* complex example, using all the configuration module functionalities, including parameter checking:
[NB-IoT configuration code](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/ENB_APP/NB_IoT_config.c) and [NB-IoT configuration include file](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/ENB_APP/NB_IoT_paramdef.h)
* very simple example, just reading a parameter set corresponding to a dedicated section: the telnetsrv_autoinit function in [common/utils/telnetsrv/telnetsrv.c, around line 726](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/telnetsrv/telnetsrv.c#L726)
* an example with run-time definition of parameters, in the logging sub-system: the log_getconfig function at the top of [openair2/UTIL/LOG/log.c](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair2/UTIL/LOG/log.c)
[Configuration module home](../config.md)
To add a new parameter in an existing section you insert an item in a `paramdef_t` array, which describes the parameters to be read in the existing `config_get` call. You also need to increment the numparams argument.
existing code:
```c
unsigned int varopt1;
paramdef_t someoptions[] = {
/*---------------------------------------------------------------------------------*/
/* configuration parameters for some module */
/* optname helpstr paramflags XXXptr defXXXval type numelt */
/*---------------------------------------------------------------------------------*/
{"opt1", "<help opt1>", 0, uptr:&varopt1, defuintval:0, TYPE_UINT, 0 },
};
config_get( someoptions,sizeof(someoptions)/sizeof(paramdef_t),"somesection");
```
new code:
```c
unsigned int varopt1;
/* varopt2 will be allocated by the config module and free at end_configmodule call
except if PARAMFLAG_NOFREE bit is set in paramflags field*/
char *varopt2;
paramdef_t someoptions[] = {
/*---------------------------------------------------------------------------------*/
/* configuration parameters for some module */
/* optname helpstr paramflags XXXptr defXXXval type numelt */
/*---------------------------------------------------------------------------------*/
{"opt1", "<help opt1>", 0, uptr:&varopt1, defuintval:0,TYPE_UINT, 0 },
{"opt2", "<help opt2>", 0, strptr:&varopt2,defstrval:"",TYPE_STRING,0 },
};
config_get( someoptions,sizeof(someoptions)/sizeof(paramdef_t),"somesection");
```
The corresponding configuration file may now include opt2 parameter in the somesection section:
```c
somesection =
{
opt1 = 3;
opt2 = "abcd";
};
```
In these examples the variables used to retrieve the parameters values are pointed by the `uptr` or `strptr` fields of the `paramdef_t` structure. After the `config_get` call `varopt1` and `varopt2` have been set to the value specified in the config file. It is also possible to specify a `NULL` value to the `< XXX >ptr` fields, which are then allocated by the config module and possibly free when calling `config_end()`, if the `PARAMFLAG_NOFREE` bit has not been set in the `paramflags` field.
The configuration module provides a mechanism to check the parameter value read from the configuration source. The following functions are implemented:
1. Check an integer parameter against a list of authorized values
1. Check an integer parameter against a list of authorized values and set the parameter to a new value
1. Check an integer parameter against a range
1. Check a C string parameter against a list of authorized values
1. Check a C string parameter against a list of authorized values and set the parameter to a new integer value
A `checkedparam_t` structure array provides the parameter verification procedures:
```c
/*
definition of the verification to be done on param opt1 and opt2.
opt1 is an integer option we must be set to 0,2,3,4 or 7 in the
config source.
if opt1 is set to 0 in the config file, it will be set to 1, etc
opt2 is C string option with the authorize values "zero","oneThird","twoThird","one"
*/
#define OPT1_OKVALUES {0,2,3,4,7}
#define OPT1_NEWVALUES {1,1,0,6,9}
#define OPT2_OKVALUES {"zero","oneThird","twoThird","one"}
#define OPT_CHECK_DESC { \
{ .s1a= { config_check_modify_integer, OPT1_OKVALUE, OPT1_NEWVALUES ,5 }}, \
{ .s3= { config_check_strval, OPT2_OKVALUES,4 }}, \
}
checkedparam_t checkopt[] = OPT_CHECK_DESC;
.....
/* assign the verification procedures to the parameters definitions */
for(int i=0 ; i < sizeof(someoptions)/sizeof(paramdesc_t) ; i ++) {
someoptions[i].chkPptr = &(checkopt[i]);
}
....
```
When you need a specific verification algorithm, you can provide your own verification function and use it in place of the available ones, in the `checkedparam_t` union. If no existing structure definition match your need, you can enhance the configuration module. You then have to add a new verification function in https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_userapi.c and add a new structure definition in the `checkedparam_t` type defined in https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
The configuration module maps a configuration file section to a `paramdef_t` structure array. One `config_get` call can be used to return the values of all the parameters described in the `paramdef_t` array.
Retrieving a single occurence of a parameter set ( a group in the libconfig terminology) is just a two steps task:
1. describe the parameters in a `paramdef_t` array
1. call the `config_get` function
[config_get example](../../config/devusage/addaparam.md)
In oai some parameters set may be instantiated a variable number of occurrences. In a configuration file this is mapped to lists of group of parameters, with this syntax:
```c
NB-IoT_MACRLCs =
/* start list element 1 */
(
/* start a group of parameters */
{
num_cc = 2;
.....
remote_s_portd = 55001;
}
),
/* start list element 2 */
(
/* start a group of parameters */
{
num_cc = 1;
......
remote_s_portd = 65001;
}
);
```
The configuration module provides the `config_getlist` call to support lists of group of parameters. Below is a commented code example, using the config_getlist call.
```c
/* name of section containing the list */
#define NBIOT_MACRLCLIST_CONFIG_STRING "NB-IoT_MACRLCs"
/*
The following macro define the parameters names, as used in the
configuration file
*/
#define CONFIG_STRING_MACRLC_CC "num_cc"
.....
#define CONFIG_MACRLC_S_PORTD "remote_s_portd"
/*
now define a macro which will be used to initialize the NbIoT_MacRLC_Params
variable. NbIoT_MacRLC_Params is an array of paramdef_t structure, each item
describing a parameter. When using the config_getlist call you must let the config
module allocate the memory for the parameters values.
*/
/*------------------------------------------------------------------------------------------------------------*/
/* optname helpstr paramflags XXXptr defXXXval type numelt */
/*------------------------------------------------------------------------------------------------------------*/
#define MACRLCPARAMS_DESC { \
{CONFIG_STRING_MACRLC_CC, NULL, 0, uptr:NULL, defintval:1, TYPE_UINT, 0}, \
............. \
{CONFIG_MACRLC_S_PORTD, NULL, 0, uptr:NULL, defintval:50021, TYPE_UINT, 0}, \
}
/*
the following macros define the indexes used to access the NbIoT_MacRLC_Params array
items. They must be maintained consistent with the previous MACRLCPARAMS_DESC macro
which is used to initialize the NbIoT_MacRLC_Params variable
*/
#define MACRLC_CC_IDX 0
.........
#define MACRLC_REMOTE_S_PORTD_IDX 16
void RCconfig_NbIoTmacrlc(void) {
/*
define and initialize the array of paramdef_t structures describing the groups of
parameters we want to read. It will be passed as the second argument of the
config_getlist call, which will use it as an input only argument.
*/
paramdef_t NbIoT_MacRLC_Params[] = MACRLCPARAMS_DESC;
/*
now define and initialize a paramlist_def_t structure which will be passed
to the config_getlist call. The first field is the only one to be initialized
it contains the name of the section to be read.
that section contains the list of group of parameters.
The two other fields are output parameters used to return respectively
a pointer to a two dimensional array of paramdef_t structures pointers, and the
number of items in the list of groups (size of first dimension, the second one
being the number of parameters in each group.
*/
paramlist_def_t NbIoT_MacRLC_ParamList = {NBIOT_MACRLCLIST_CONFIG_STRING,NULL,0};
/*
the config_getlist will allocate the second field of the paramlist_def_t structure, a
two dimensional array of paramdef_t pointers. In each param_def item it will allocate
the value pointer and set the value to what it will get from the config source. The
numelt field of the paramlist_def_t structure will be set to the number of groups of
parameters in the list.
in this example the last argument of config_getlist is unused, it may contain a
character string, used as a prefix for the section name. It has to be specified when the
list to be read is under another section.
*/
config_getlist( &NbIoT_MacRLC_ParamList,NbIoT_MacRLC_Params,
sizeof(NbIoT_MacRLC_Params)/sizeof(paramdef_t),
NULL);
/*
start a loop in the nuber of groups in the list, the numelt field of the
paramlist_def_t structure has been set in the config_getlist call
*/
for (j=0 ; j<NbIoT_MacRLC_ParamList.numelt ; j++) {
..........
/* access the MACRLC_REMOTE_S_PORTD parameter in the j ieme group of the list */
RC.nb_iot_mac[j]->eth_params_s.remote_portd =
*(NbIoT_MacRLC_ParamList.paramarray[j][MACRLC_REMOTE_S_PORTD_IDX].iptr);
............
} // MacRLC_ParamList.numelt > 0
}
```
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
```c
configmodule_interface_t *load_configmodule(int argc, char **argv)
```
* Parses the command line options, looking for the –O argument
* Loads the `libparams_<configsource>.so` (today `libparams_libconfig.so`) shared library
* Looks for `config_<config source>_init` symbol and calls it , passing it an array of string corresponding to the « : » separated strings used in the –O option
* Looks for `config_<config source>_get`, `config_<config source>_getlist` and `config_<config source>_end` symbols which are the three functions a configuration library should implement. Get and getlist are mandatory, end is optional.
* Stores all the necessary information in a `configmodule_interface_t structure`, which is of no use for caller as long as we only use one configuration source.
```c
void End_configmodule(void)
```
* Free memory which has been allocated by the configuration module since its initialization.
* Possibly calls the `config_<config source>_end` function
```c
int config_get(paramdef_t *params,int numparams, char *prefix)
```
* Reads as many parameters as described in params, they must all be in the same configuration file section
* Calls the `config_<config source>_get` function
* Calls the `config_process_cmdline` function
* `params` points to an array of `paramdef_t` structures which describes the parameters to be read, possibly including a pointer to a checking function. The following bits can possibly be set in the `paramflags` mask before calling
- `PARAMFLAG_MANDATORY`: -1 is returned if the parameter is not explicitly defined in the config source.
- `PARAMFLAG_DISABLECMDLINE`: parameter cannot be modified via the command line
- `PARAMFLAG_DONOTREAD`: ignore the parameter, can be used at run-time, to alter a pre-defined `paramdef_t` array which is used in several `config_get` or/and `config_getlist` calls.
- `PARAMFLAG_NOFREE`: do not free the memory possibly allocated by the config module to store the value of the parameter. Default behavior is for the config module to free the memory it has allocated when the `config_end` function is called.
- `PARAMFLAG_BOOL`: Only relevant for integer types. tell the config module that when processing the command line, the corresponding option can be specified without any arggument and that in this case it must set the value to 1.
* `params` is also used as an output parameter, `< XXX >ptr >` field is used by the config module to store the value it has read. The following bits can possibly be set in the `paramflags` mask after the call:
- `PARAMFLAG_MALLOCINCONFIG`: memory has been allocated for the ` < XXX >ptr > ` field
- `PARAMFLAG_PARAMSET`: parameter has been found in the config source, it is not set to default value.
- `PARAMFLAG_PARAMSET`: parameter has been set to its default value
* `numparams` is the number of entries in the params array
* `prefix` is a character string to be appended to the parameters name, it defines the parameters position in the configuration file hierarchy (the section name in libconfig terminology).
* The returned value is the number of parameters which have been assigned a value or -1 if a severe error occured
```c
int config_libconfig_getlist(paramlist_def_t *ParamList, paramdef_t *params, int numparams, char *prefix)
```
* Reads multiple occurrences of a parameters array
* Calls the `config_<config source>_get` function for each list occurrence
* `params` points to an array of `paramdef_t` structures which describes the parameters in each occurrence of the list
* `ParamList` points to a structure, where `paramarray` field points to an array of `paramdef_t` structure, allocated by the function. It is used to return the values of the parameters.
* The returned value is the number of occurrences in the list or -1 in case of severe error
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
# `paramdef_t`structure
It is defined in include file [ common/config/config_paramdesc.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h#L103). This structure is used by developers to describe parameters and by the configuration module to return parameters value. A pointer to a `paramdef_t` array is passed to `config_get` and `config_getlist` calls to instruct the configuration module what parameters it should read.
| Fields | Description | I/O |
|:-----------|:------------------------------------------------------------------|----:|
| `optname` | parameter name, as used when looking for it in the config source, 63 bytes max (64 with trailing \0) | I |
| `helstr` | pointer to a C string printed when using --help on the command line | I |
| `strptr` `strlistptr` `u8ptr` `i8ptr` `u16ptr` `i16ptr` `uptr` `iptr` `u64ptr` `i64ptr` `dblptr` `voidptr` | a pointer to a variable where the parameter value(s) will be returned. This field is an anonymous union, the supported pointer types have been built to avoid type mismatch warnings at compile time. | O |
| `defstrval` `defstrlistval` `defuintval` `defintval` `defint64val` `defintarrayval` `defdblval` | this field is an anonymous union, it can be used to define the default value for the parameter. It is ignored if `PARAMFLAG_MANDATORY` is set in the `paramflags` field.| I |
| `type` | Supported parameter types are defined as integer macros. Supported simple types are `TYPE_STRING`, parameter value is returned in `strptr` field, `TYPE_INT8` `TYPE_UINT8` `TYPE_INT16` `TYPE_UINT16` `TYPE_INT32` `TYPE_UINT32` `TYPE_INT64` `TYPE_UINT64`, parameter value is returned in the corresponding uXptr or iXptr, `TYPE_MASK`, value is returned in `u32ptr`, `TYPE_DOUBLE` value is returned in `dblptr`, `TYPE_IPV4ADDR` value is returned in binary, network bytes order in `u32ptr` field. `TYPE_STRINGLIST`, `TYPE_INTARRAY` and `TYPE_UINTARRAY` are multiple values types. Multiple values are returned in respectively, `strlistptr`, `iptr` and `uptr` fields which then point to arrays. The `numelt` field gives the number of item in the array. | I |
| `numelt` | For `TYPE_STRING` where `strptr` points to a preallocated string, this field must contain the size in bytes of the available memory. For all multiple values types, this field contains the number of values in the value field.| I/O |
| `chkPptr` | possible pointer to the structure containing the info used to check parameter values | I |
| `processedvalue` | When `chkPptr` is not `ǸULL`, is used to return a value, computed from the original parameter, as read from the configuration source. | O |
# `paramlist_def_t`structure
It is defined in include file [ common/config/config_paramdesc.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h#L160).
It is used as an argument to `config_getlist` calls, to get values of multiple occurrences of group of parameters.
| Fields | Description | I/O |
|:-----------|:------------------------------------------------------------------|----:|
| `listname` | Name of the section containing the list, 63 bytes max (64 with trailing \0). It is used to prefix each paramater name when looking for its value. In the libconfig syntax, the parameter name full path build by the configuration module is: listname.[occurence index].optname. | I |
| `paramarray` | Pointer to an array of `ǹumelt` `paramdef_t` pointers. It is allocated by the configuration module and is used to return the parameters values. All input fields of each `paramdef_t` occurence are a copy of the `paramdef_t` argument passed to the `config_getlist` call. | O |
| `numelt` | Number of items in the `paramarray` field | O |
# `checkedparam_t` union
It is defined in include file [ common/config/config_paramdesc.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/config/config_paramdesc.h#L62).
This union of structures is used to provide a parameter checking mechanism. Each `paramdef_t` instance may include a pointer to a `checkedparam_t`structure which is then used by the configuration module to check the value it got from the config source.
Each structure in the union provides one parameter verification method, which returns `-1` when the verification fails. Currently the following structures are defined in the `checkedparam_t` union:
| structure name | Description |
|:-----------|:------------------------------------------------------------------|----:|
| `s1` | check an integer against a list of authorized values |
| `s1a` | check an integer against a list of authorized values and set the parameter value to another integer depending on the read value|
| `s2` | check an integer against an authorized range, defined by its min and max value|
| `s3` | check a string against a list of authorized values |
| `s3a` | check a string against a list of authorized values and set the parameter value to an integer depending on the read value|
| `s4` | generic structure, to be used to provide a specific, not defined in the configuration module, verification algorithm |
each of these structures provide the required fields to perform the specified parameter check. The first field is a pointer to a function, taking one argument, the `paramdef_t` structure describing the parameter to be checked. This function is called by the configuration module, in the `config_get` call , after the parameter value has been set, it then uses the other fields of the structure to perform the check.
The configuration module provides an implementation of the functions to be used to check parameters, qs described below.
## `s1` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f1` | pointer to the checking function. Initialize to `config_check_intval` to use the config module implementation |
| `okintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the authorized values |
| `num_okintval` | number of used values in `okintval` |
## `s1a` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f1a` | pointer to the checking function. Initialize to `config_check_modify_integer` to use the config module implementation |
| `okintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the authorized values |
| `setintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the values to be used for the parameter. The configuration module implementation set the parameter value to `setintval[i]` when the configured value is `okintval[i]` |
| `num_okintval` | number of used values in `okintval` and `setintval` |
## `s2` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f2` | pointer to the checking function. Initialize to `config_check_intrange` to use the config module implementation |
| `okintrange` | array of 2 integers containing the min and max values for the parameter |
## `s3` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f3` | pointer to the checking function. Initialize to `config_check_strval` to use the config module implementation |
| `okstrval` | array of `CONFIG_MAX_NUMCHECKVAL` C string pointers containing the authorized values |
| `num_okstrval` | number of used values in `okstrtval` |
## `s3a` structure
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f3a` | pointer to the checking function. Initialize to `config_checkstr_assign_integer` to use the config module implementation |
| `okstrval` | array of `CONFIG_MAX_NUMCHECKVAL` C string pointers containing the authorized values |
| `setintval` | array of `CONFIG_MAX_NUMCHECKVAL` integers containing the values to be used for the parameter. The configuration module implementation set the parameter value to `setintval[i]` when the configured value is `okstrval[i]` |
| `num_okstrval` | number of used values in `okintval` and `setintval` |
## `s4` and `s5` structures
| field | Description |
|:-----------|:------------------------------------------------------------------|
| `f4` or `f5` | pointer to the checking function. they are generic structures to be used when no existing structure provides the required parameter verification. `f4` takes one argument, the `paramdef_t` structure corresponding to the parameter to be checked (`int (*f4)(paramdef_t *param)`), `f5` taxes no argument (`void (*checkfunc)(void)`) |
[Configuration module developer main page](../../config/devusage.md)
[Configuration module home](../../config.md)
-O is the only mandatory command line option to start the eNodeb softmodem (lte-softmodem executable), it is used to specify the configuration source with the associated parameters:
```bash
$ ./lte-softmodem -O <configsource>:<parameter1>:<parameter2>:...
```
The configuration module can also be used without a configuration source, ie to only parse the command line. In this case the -O switch is optional. This mode is used in the ue-softmodem executable and by the phy_simulators executables (ulsim, dlsim)
Currently the available config sources are:
- **libconfig**: libconfig file. [libconfig file format](http://www.hyperrealm.com/libconfig/libconfig_manual.html#Configuration-Files) Parameter1 is the file path and parameter 2 can be used to specify the level of console messages printed by the configuration module.
```bash
$ ./lte-softmodem -O libconfig:<config>:dbgl<debuglevel>
```
- **cmdlineonly**: command line only, the default mode for lte-uesoftmodem and the phy simiulators. In this case -O may be used to specify the config module debug level.
The debug level is a mask:
* bit 1: print parameters values
* bit 2: print memory allocation/free performed by the config module
* bit 3: print command line processing messages
* bit 4: disable execution abort when parameters checking fails
As a oai user, you may have to use bit 1 (dbgl1) , to check your configuration and get the full name of a parameter you would like to modify on the command line. Other bits are for developers usage, (dbgl7 will print all debug messages).
```bash
$ ./lte-softmodem -O libconfig:<config>:dbgl1
```
```bash
$ ./lte-uesoftmodem -O cmdlineonly:dbgl1
```
For the lte-softmodem (the eNodeB) The config source parameter defaults to libconfig, preserving the initial -O option format. In this case you cannot specify the debug level.
```bash
$ ./lte-softmodem -O <config>
```
Configuration file parameters, except for the configuration file path, can be specified in a **config** section in the configuration file:
```
config:
{
debugflags = 1;
}
```
Configuration files examples can be found in the targets/PROJECTS/GENERIC-LTE-EPC/CONF sub-directory of the oai source tree. To minimize the number of configuration file to maintain, any parameter can also be specified on the command line. For example to modify the lte bandwidth to 20 MHz where the configuration file specifies 10MHz you can enter:
```bash
$ ./lte-softmodem -O <config> --eNBs.[0].component_carriers.[0].N_RB_DL 100
```
As specified earlier, use the dbgl1 debug level to get the full name of a parameter you would like to modify on the command line.
[Configuration module home](../config.md)
\ No newline at end of file
# OAI shared library loader
Shared libraries usage is modularization mechanism which provides the following advantages:
1. Prevents including in the main executable code which is not used in a given configuration
1. Provides flexibility, several implementation of a given functionality can be chosen at run-time, without any compilation step. For example you can build several devices (USRP, BladeFR, LimeSDR) and choose which one you want to use on the command line or via the configuration.
1. Makes code evolution easier: as soon as the shared library interface is clearly defined, you can work on the functionality implemented in a shared library while regularly updating the other components of the code. You can decide to develop your own version of a functionality, decide to deliver it or not, letting the user decide wwhat version he wants to use.
The main drawback is a performance cost at init time, when loading libraries.
## Documentation
* [runtime usage](loader/rtusage.md)
* [developer usage](loader/devusage.md)
* [module architecture](loader/arch.md)
[oai Wikis home](https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home)
\ No newline at end of file
# loader source files
The oai shared library loader is implemented in two source files, located in [common/utils](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils)
1. [load_module_shlib.c](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/load_module_shlib.c) contains the loader implementation
1. [load_module_shlib.h](https://gitlab.eurecom.fr/oai/openairinterface5g/tree/develop/common/utils/load_module_shlib.h) is the loader include file containing both private and public data type definitions. It also contain API prototypes.
[loader home page](../loader.md)
\ No newline at end of file
The configuration module objectives are
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.
As a developer you may need to look at these sections:
* [loading a shared library](devusage/loading.md)
* [loader API](devusage/api.md)
* [loader public structures](devusage/struct.md)
Loader usage examples can be found in oai sources:
* device and transport initialization code: [function `load_lib` in *targets/ARCH/COMMON/__common_lib.c__* ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/targets/ARCH/COMMON/common_lib.c#L91)
* turbo encoder and decoder initialization: [function `load_codinglib`in *openair1/PHY/CODING/__coding_load.c__*](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/openair1/PHY/CODING/coding_load.c#L113)
[loader home page](../loader.md)
Loader API is defined in the [common/utils/load_module_shlib.h](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/load_module_shlib.h) include file.
```c
int load_module_shlib(char *modname,loader_shlibfunc_t *farray, int numf)
```
* possibly initializes the loader, if it has not been already initialized
* Formats the full shared library path, using the `modname` argument and the loader `shlibpath` and `shlibversion`configuration parameters.
* loads the shared library, using the dlopen system call
* looks for `< modname >_autoinit` symbol, using the `dlsym` system call and possibly call the corresponding function.
* looks for `< modname >_checkbuildver` symbol, using the `dlsym` system call and possibly calls the corresponding function. If the return value of this call is `-1`, program execution is stopped. It is the responsibility of the shared library developer to implement or not a `< modname >_checkbuildver` function and to decide if a version mismatch is a fatal condition. The `< modname >_checkbuildver` function must match the `checkverfunc_t` function type. The first argument is the main executable version, as set in the `PACKAGE_VERSION` macro defined in the [oai CMakeLists](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/cmake_targets/CMakeLists.txt#L218), around line 218. The second argument points to the shared library version which should be set by the `< modname >_checkbuildver` function.
* If the farray pointer is null, looks for `< modname >_getfarray` symbol, calls the corresponding function when the symbol is found. `< modname >_getfarray` takes one argument, a pointer to a `loader_shlibfunc_t` array, and returns the number of items in this array, as defined by the `getfarrayfunc_t` type. The `loader_shlibfunc_t` array returned by the shared library must be fully filled (both `fname` and `fptr` fields).
* looks for the `numf` function symbols listed in the `farray[i].fname` arguments and set the corresponding `farray[i].fptr`function pointers
```c
void * get_shlibmodule_fptr(char *modname, char *fname)
```
Returns a pointer to the symbol `fname`, defined in module `modname`, or `NULL` if the symbol is not found.
[loader home page](../../loader.md)
[loader developer home page](../devusage.md)
\ No newline at end of file
Implementing a shared library dynamic load using the oai loader is a two steps task:
1. define the `loader_shlibfunc_t` array, describing the list of externally available functions implemented in the library. This is the interface of the module.
1. Call the `load_module_shlib` function, passing it the previously defined array and the number of items in this array. The first argument to `load_module_shlib` is the name identifying the module, which is also used to format the corresponding library name, as described [here](loader/rtusage#shared-library-names)
After a successful `load__module_shlib` call, the function pointer of each `loader_shlibfunc_t` array item has been set and can be used to call the corresponding function.
Typical loader usage looks like:
```c
/* shared library loader include file */
#include "common/utils/load_module_shlib.h"
.............
/*
define and initialize the array, describing the list of functions
implemented in "mymodule"
*/
loader_shlibfunc_t mymodule_fdesc[2];
mymodule_fdesc[0].fname="mymodule_f1";
mymodule_fdesc[1].fname="mymodule_f2";
/*
load the library, it's name must be libmymod.so. Configuration can be
used to specify a specific path to look for libmymod.so. Configuration
can also specify a version, for example "V1", in this case the loader
will look for libmymodV1.so
*/
ret=load_module_shlib("mymod",mymodule_fdesc, sizeof(mymodule_fdesc)/sizeof(loader_shlibfunc_t));
if (ret < 0) {
fprintf(stderr,"Library couldn't be loaded\n");
} else {
/*
library has been loaded, we probably want to call some functions...
*/
ret=((funcf1_t)mymodule_fdesc[0].fptr)();
..................
/*
later and/or somewhere else in the code you may want to call function "mymodule_f2"
You can use the loader get_shlibmodule_fptr(char *modname, char *fname) function
to retrieve the pointer to that function
*/
funcf2_t *f2;
int ret;
int intarg1;
char *strarg;
........................
f2 = (funcf2_t)get_shlibmodule_fptr("mymodule", "mymodule_f2")
if (f2 != NULL) {
ret = f2(intarg1,strarg);
}
...............
```
When loading a shared library the loader looks for a symbol named `< module name > _autoinit` and, if it finds it, calls it. The `autoinit` function is called without any argument and the returned value, if any, is not tested.
[loader home page](../loader.md)
[loader developer home page](../../loader/devusage.md)
\ No newline at end of file
# `loader_shlibfunc_t`structure
It is defined in include file [ common/util/load_module_shlib.h ](https://gitlab.eurecom.fr/oai/openairinterface5g/blob/develop/common/utils/load_module_shlib.h#L38). This structure is used to list the symbols that should be searched by the loader when calling the `load_module_shlib` function.
| Fields | Description | I/O |
|:-----------|:------------------------------------------------------------------|----:|
| `fname` | symbol name, is passed to the [`dlsym`](http://man7.org/linux/man-pages/man3/dlsym.3.html) system call performed by the loader to get a pointer to the symbol | I |
| `fptr` | pointer to the symbol name, set by the loader. `fptr` is defined as a `int (*fptr)(void)` function type | O |
[loader home page](../../loader.md)
[loader developer home page](../devusage.md)
\ No newline at end of file
## shared library names
Shared library full names are built by the loader using the format:
> < *path* >/lib< *module name* >< *module version* >.so
1. the < *module name* > is defined at development time, it comes from the `modname` argument of the `load_module_shlib` call.
1. the < *module version* > and < *path* > optional parameters, are defined at run-time, depending on the configuration.
## loader parameters
The loader is using the [configuration module](../../../config/DOC/config.md), and defines global and per library parameters. Global parameters must be specified under the **loader** section and library specific parameters under a **loader.<*module name*>** section. Module specific parameters override the global parameters.
### Global loader parameters
| name | type | default | description |
|:---:|:---:|:---:|:----|
| `shlibpath` | `string of char` | `""` | directory path used to look for shared libraries, may be superseded by the library specific `shlibpath`.|
| `maxshlibs` | `integer` | 10 | Maximum number of shared libraries the loader can manage. |
### library specific loader parameters
| name | type | default | description |
|:---:|:---:|:---:|:----|
| `shlibpath` | `string of char` | `""` | directory path used to look for this shared library.|
| `shlibversion` | `string of char` | `""` | version to be used to load this shared library.|
### loader configuration examples
The following configuration file example just reproduce the default loader parameters:
```c
loader :
{
shlibpath = "./";
maxshlibs = 10;
liboai_device :
{
shlibpath = "./";
shlibversion = "";
}
};
```
If you want to load a device called *liboai_device_USRP.so* without writting a specific configuration, you can start the softmodem using the following command:
> ./lte-softmodem -O libconfig:/usr/local/oai/openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.nbiot.band7.tm1.50PRB.usrpb210.conf:dbgl5 --loader.oai_device.shlibversion _USRP
With this latest example, nn the softmodem logs, you can check that the right device library has been loaded:
```bash
[LIBCONFIG] loader.oai_device.shlibpath not found in /usr/local/oai/develop-nb-iot-merge/openairinterface5g/targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.nbiot.band7.tm1.50PRB.usrpb210.conf
[LIBCONFIG] loader.oai_device.shlibversion set to default value ""
[LIBCONFIG] loader.oai_device: 1/2 parameters successfully set, (1 to default value)
[CONFIG] shlibversion set to _USRP from command line
[CONFIG] loader.oai_device 1 options set from command line
```
[loader home page](../loader.md)
\ No newline at end of file
......@@ -14,10 +14,10 @@
#define DEFAULT_IP "127.0.0.1"
#define DEFAULT_PORT 9999
#define NO_PREAMBLE -1
#define DEFAULT_LIVE_IP "127.0.0.1"
#define DEFAULT_LIVE_PORT 2021
int no_sib = 0;
int no_mib = 0;
#define NO_PREAMBLE -1
typedef struct {
int socket;
......@@ -46,6 +46,15 @@ typedef struct {
int rar_frame;
int rar_subframe;
int rar_data;
/* config */
int no_mib;
int no_sib;
int max_mib;
int max_sib;
int live;
/* runtime vars */
int cur_mib;
int cur_sib;
} ev_data;
void trace(ev_data *d, int direction, int rnti_type, int rnti,
......@@ -104,7 +113,11 @@ void dl(void *_d, event e)
{
ev_data *d = _d;
if (e.e[d->dl_rnti].i == 0xffff && no_sib) return;
if (e.e[d->dl_rnti].i == 0xffff) {
if (d->no_sib) return;
if (d->max_sib && d->cur_sib == d->max_sib) return;
d->cur_sib++;
}
trace(d, DIRECTION_DOWNLINK,
e.e[d->dl_rnti].i != 0xffff ? C_RNTI : SI_RNTI, e.e[d->dl_rnti].i,
......@@ -117,7 +130,9 @@ void mib(void *_d, event e)
{
ev_data *d = _d;
if (no_mib) return;
if (d->no_mib) return;
if (d->max_mib && d->cur_mib == d->max_mib) return;
d->cur_mib++;
trace(d, DIRECTION_DOWNLINK, NO_RNTI, 0,
e.e[d->mib_frame].i, e.e[d->mib_subframe].i,
......@@ -269,9 +284,18 @@ void usage(void)
" -ip <IP address> send packets to this IP address (default %s)\n"
" -p <port> send packets to this port (default %d)\n"
" -no-mib do not report MIB\n"
" -no-sib do not report SIBs\n",
" -no-sib do not report SIBs\n"
" -max-mib <n> report at maximum n MIB\n"
" -max-sib <n> report at maximum n SIBs\n"
" -live run live\n"
" -live-ip <IP address> tracee's IP address (default %p)\n"
" -live-port <por> tracee's port (default %d)\n"
"-i and -live are mutually exclusive options. One of them must be provided\n"
"but not both.\n",
DEFAULT_IP,
DEFAULT_PORT
DEFAULT_PORT,
DEFAULT_LIVE_IP,
DEFAULT_LIVE_PORT
);
exit(1);
}
......@@ -288,6 +312,9 @@ int main(int n, char **v)
ev_data d;