Attention is currently required from: laforge, pespin.

View Change

1 comment:

• File include/osmocom/gsm/protocol/gsm_12_21.h:

  • Patch Set #2, Line 294: enum abis_nm_par_defaults {

    it makes no sense to have this as enums, because they are not different types of the same thing nor […]

    What's the drawback of using an enum here?

    These defaults were hardcoded in existing code. When that wasn't the case I checked with the specs (I think I may even have done that here, not sure anymore though since it's been a while).

    For instance:

    ```
    osmo-bsc$ ag -A10 rlc_cfg_default
    src/osmo-bsc/bts.c
    126:static const struct gprs_rlc_cfg rlc_cfg_default = {
    127- .parameter = {
    128- [RLC_T3142] = 20,
    129- [RLC_T3169] = 5,
    130- [RLC_T3191] = 5,
    131- [RLC_T3193] = 160, /* 10ms */
    132- [RLC_T3195] = 5,
    133- [RLC_N3101] = 10,
    134- [RLC_N3103] = 4,
    135- [RLC_N3105] = 8,
    136- [CV_COUNTDOWN] = 15,
    ```

    and the same I think for NSE timers.

    I think we had had a short back and forth about this already, iirc I did put these or similar values in the respective header for the standard defining the timers, but you were against that saying it was more related to abis/O&M since it's values communicated over PCU IF and gave pointers to this header or something similar.

    Whatever it is... where would you put default values such as these, if not here?
    Should we add a centralised `gsm_data.h` to libosmocore that keeps shared values?

To view, visit change 31877. To unsubscribe, or for help writing mail filters, visit settings.