path: root/tests/tdef
AgeCommit message (Collapse)AuthorFilesLines
2020-11-15tests: Fix tdef_test on 32bit platformsPau Espin Pedrol2-9/+9
100 minutes = 6000000000 microseconds was too big to be stored in an unsigned long in a 32bit platform, making the test print 4294967295 instead. Let's set a smaller value to have the test happy on 32 bits. Change-Id: Ic0d009f00a69cee59f2d3fc0b40ecdc97d81c75c
2020-11-15Revert "tests: Fix tdef_test on 32bit platforms"Pau Espin Pedrol2-6/+6
This was not the issue, see next commit fixing the correct issue. This reverts commit af10e48c1bf7ec40678b9a4387fc50ab0846b467. Change-Id: Ifa1057ac55fcacdeb55ecdaac1ac3ddcca7d6d65
2020-11-12tests: Fix tdef_test on 32bit platformsPau Espin Pedrol2-6/+6
60 seconds = 6000000000 microseconds was too big to be stored in an unsigned long in a 32bit platform, making the test print 4294967295 instead. Let's set a smaller value to have the test happy on 32 bits. Change-Id: I97d53f6b7b410cef4b3f3fbe3162626fcdd7b05a
2020-11-11tdef: Introduce OSMO_TDEF_US unitPau Espin Pedrol2-2/+36
Some applications may need submillisecond timers, such as those interacting with modbus serial lines (RS-485, RTU), which require timers of values around 1.5 char-time (T1.5), where a data char is composed of 11 bits sent on the line: 1 start bit, 8 data bits, 1 stop bit, and and parity bit (or 2nd stop bits if no parity). For instance, for a baudrate of 9600: 1.5 * 11 / 9600 = 1.718 ms = 1718 us So having a granularity of MS is not enough here. Change-Id: I71848d7c1ee0649929ce07680ee7320bb2a42f0e
2019-12-01Check for osmo_fsm_register() error return valueHarald Welte1-1/+1
Change-Id: Idbc1557739b2a253b73914e6f1f18a6d169d882e
2019-10-07tdef_test: verify case where osmo_tdef_set returns -EEXISTPau Espin Pedrol2-0/+4
Change-Id: I436daa804aac11622fde24afe9ea35193d9e9beb
2019-10-07tdef: Introduce min_val and max_val fieldsPau Espin Pedrol4-3/+87
This is useful for timers expected to have a range of valid or expected values. Validation is done at runtime when timer values are set by the app or by the user through the VTY. Related: OS#4190 Change-Id: I4661ac41c29a009a1d5fc57d87aaee6041c7d1b2
2019-06-14vty: command.c: Fix: multi-choice args are no longer passed incomplete to ↵Pau Espin Pedrol1-5/+6
vty func For instance, take command "multi0 (one|two|three)": If user executes "multi0 tw", VTY func will receive argv[0]="two" instead of argv[0]="tw". Fixes: OS#4045 Change-Id: I91b6621ac3d87fda5412a9b415e7bfb4736c8a9a
2019-06-11vty: command.c: Fix is_cmd_ambiguous() returning always 0Pau Espin Pedrol1-35/+6
inner block defined variable "enum match_type ret" was being masking outter block variable "int ret = 0". The ret variable was being given non zero values only inside the inner block, so that change was done on the inner variable and not the outer one, which is returned. Fixes: 5314c513f23688462d7f7937e5ae5e0d5cd4548e Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
2019-03-07fsm: add osmo_fsm_inst_state_chg_keep_or_start_timer()Neels Hofmeyr2-4/+4
During FSM design for osmo-msc, I noticed that the current behavior that keep_timer=true doesn't guarantee a running timer can make FSM design a bit complex, especially when using osmo_tdef for timeout definitions. A desirable keep_timer=true behavior is one that keeps the previous timer running, but starts a timer if no timer is running yet. The simplest example is: a given state repeatedly transitions back to itself, but wants to set a timeout only on first entering, avoiding to restart the timeout on re-entering. Another example is a repeated transition between two or more states, where the first time we enter this group a timeout should start, but it should not restart from scratch on every transition. When using osmo_tdef timeout definitions for this, so far separate meaningless states have to be introduced that merely set a fixed timeout. To simplify, add osmo_fsm_inst_state_chg_keep_or_start_timer(), and use this in osmo_tdef_fsm_inst_state_chg() when both keep_timer == true *and* T != 0. In tdef_test.ok, the changes show that on first entering state L, the previous T=1 is now kept with a large remaining timeout. When entering state L from O, where no timer was running, this time L's T123 is started. Change-Id: Id647511a4b18e0c4de0e66fb1f35dc9adb9177db
2019-03-06fix tdef_test.c: do call the function-to-test in all casesNeels Hofmeyr3-19/+19
Always call osmo_tdef_fsm_inst_state_chg(), also when no timeout is defined. When there is no timeout defined for a state, tdef_test.c tries to be smart and print different output. In that mess, I missed the fact that osmo_tdef_fsm_inst_state_chg() isn't always called as it should. In the same mess, the resulting state was never printed until the preceding patch, which helped to hide this bug. Change-Id: I1d953d99854422bff8eb32f051e9c6147bc836b6
2019-03-06tdef_test: tweak output to prepare for a fixNeels Hofmeyr3-21/+24
- Always print the state after a state transition. This shows that actually state transitions are missing for states that have no timer defined. This is a bug in tdef_test.c, to be fixed subsequently. - Instead of total time passed since start, print the individual fake time intervals. Omit initial useless zero fake time advance. - Add two more state transitions, back out from and into a state that has no timeout set. Change-Id: Icb31af96d37741e256ff07868f3d4f5c48cdda74
2019-03-06represent negative T-timers as Osmocom-specific X-timersNeels Hofmeyr2-30/+60
fi->T values are int, i.e. can be negative. Do not log them as unsigned, but define a distinct timer class "Xnnnn" for negative T values: i.e. for T == -1, print "Timeout of X1" instead of "Timeout of T4294967295". The negative T timer number space is useful to distinguish freely invented timers from proper 3GPP defined T numbers. So far I was using numbers like T993210 or T9999 for invented T, but X1, X2 etc. is a better solution. This way we can make sure to not accidentally define an invented timer number that actually collides with a proper 3GPP specified timer number that the author was not aware of at the time of writing. Add OSMO_T_FMT and OSMO_T_FMT_ARGS() macros as standardized timer number print format. Use that in fsm.c, tdef_vty.c, and adjust vty tests accordingly. Mention the two timer classes in various API docs and VTY online-docs. Change-Id: I3a59457623da9309fbbda235fe18fadd1636bff6
2019-02-06platform independence fix: tdef range testsNeels Hofmeyr7-133/+489
Run INT_MAX and ULONG_MAX related tests only manually, remove from automatic testing. This will hopefully fix recent build failures on various platforms. Add a 64 bit output example for expected results when invoking `./tdef_test range'. This is not checked automatically and merely serves for manual reference. For vty tests, use 32bit max values instead of INT_MAX and ULONG_MAX. Change-Id: I6242243bde1d7ddebb858512a1f0b07f4ec3e5c2
2019-02-04add osmo_tdef API, originally adopted from osmo-bsc T_defNeels Hofmeyr8-0/+2053
Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more consistent. Upgrade to first class API: - add timer grouping - add generic vty support - add mising API doc - add C test - add VTY transcript tests, also as examples for using the API From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API. The root reason for moving to libosmocore is that I want to use the mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible place for this. osmo_tdef provides: - a list of Tnnnn (GSM) timers with description, unit and default value. - vty UI to allow users to configure non-default timeouts. - API to tie T timers to osmo_fsm states and set them on state transitions. - a few standard units (minute, second, millisecond) as well as a custom unit (which relies on the timer's human readable description to indicate the meaning of the value). - conversion for standard units: for example, some GSM timers are defined in minutes, while our FSM definitions need timeouts in seconds. Conversion is for convenience only and can be easily avoided via the custom unit. By keeping separate osmo_tdef arrays, several groups of timers can be kept separately. The VTY tests in tests/tdef/ showcase different schemes: - tests/vty/tdef_vty_test_config_root.c: Keep several timer definitions in separately named groups: showcase the osmo_tdef_vty_groups*() API. Each timer group exists exactly once. - tests/vty/tdef_vty_test_config_subnode.c: Keep a single list of timers without separate grouping. Put this list on a specific subnode below the CONFIG_NODE. There could be several separate subnodes with timers like this, i.e. continuing from this example, sets timers could be separated by placing timers in specific config subnodes instead of using the global group name. - tests/vty/tdef_vty_test_dynamic.c: Dynamically allocate timer definitions per each new created object. Thus there can be an arbitrary number of independent timer definitions, one per allocated object. T_def was introduced during the recent osmo-bsc refactoring for inter-BSC handover, and has proven useful: - without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be programmed with the right timeout value, for all code paths that invoke this state change. It is a likely source of errors to get one of them wrong. By defining a T timer exactly for an FSM state, the caller can merely invoke the state change and trust on the original state definition to apply the correct timeout. - it is helpful to have a standardized config file UI to provide user configurable timeouts, instead of inventing new VTY commands for each separate application of T timer numbers. Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5