aboutsummaryrefslogtreecommitdiffstats
path: root/src/plugins/ioam/encap/ip6_ioam_pot.c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-07misc: Purge unused pg includesNeale Ranns1-1/+0
Type: style Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I26a19e42076e031ec5399d5ca05cb49fd6fbe1cd
2019-05-16init / exit function orderingDave Barach1-24/+23
The vlib init function subsystem now supports a mix of procedural and formally-specified ordering constraints. We should eliminate procedural knowledge wherever possible. The following schemes are *roughly* equivalent: static clib_error_t *init_runs_first (vlib_main_t *vm) { clib_error_t *error; ... do some stuff... if ((error = vlib_call_init_function (init_runs_next))) return error; ... } VLIB_INIT_FUNCTION (init_runs_first); and static clib_error_t *init_runs_first (vlib_main_t *vm) { ... do some stuff... } VLIB_INIT_FUNCTION (init_runs_first) = { .runs_before = VLIB_INITS("init_runs_next"), }; The first form will [most likely] call "init_runs_next" on the spot. The second form means that "init_runs_first" runs before "init_runs_next," possibly much earlier in the sequence. Please DO NOT construct sets of init functions where A before B actually means A *right before* B. It's not necessary - simply combine A and B - and it leads to hugely annoying debugging exercises when trying to switch from ad-hoc procedural ordering constraints to formal ordering constraints. Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c Signed-off-by: Dave Barach <dave@barachs.net>
2018-10-23c11 safe string handling supportDave Barach1-1/+1
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2017-02-13VPP-632 : InBand OAM AnalyserAkshayaNadahalli1-16/+5
Refer to jira ticket for more details. Change-Id: I6facb9ef8553a21464f9a2e612706f152badbb68 Signed-off-by: AkshayaNadahalli <anadahal@cisco.com>
2017-01-01Move java,lua api and remaining plugins to src/Damjan Marion1-0/+276
Change-Id: I1c3b87e886603678368428ae56a6bd3327cbc90d Signed-off-by: Damjan Marion <damarion@cisco.com>