Merge branch 'develop_integration_2018_w46' into 'develop'

Develop integration 2018 w46

See merge request oai/openairinterface5g!445

common/config/DOC/config.md

+# 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)

common/config/DOC/config/arch.md

+# 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

common/config/DOC/config/devusage.md

+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)

common/config/DOC/config/devusage/addaparam.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)

common/config/DOC/config/devusage/addparamset.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)

common/config/DOC/config/devusage/api.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)

common/config/DOC/config/devusage/struct.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)

common/config/DOC/config/rtusage.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

common/utils/DOC/loader.md

+# 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

common/utils/DOC/loader/arch.md

+# 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

common/utils/DOC/loader/devusage.md

+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)

common/utils/DOC/loader/devusage/api.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

common/utils/DOC/loader/devusage/loading.md

+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

common/utils/DOC/loader/devusage/struct.md

+# `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

common/utils/DOC/loader/rtusage.md

+## 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`.|