This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comOk, so I finally took some time to re-read this.
First a quick comment on each patch.
Patch 1/4: See below
Patch 2/4: Didn't really look deeply yet, but at first glance looks
OK, I'd say let's focus on getting the infra of patch 1 merged first.
Patch 3/4: I'm pretty sure -march=native will wreck cross-compiling
Patch 4/4: Looks good
For patch 1:
* About the state persistence, let's just ignore it for now. It does
cost some performance but there is no easy fix, the perf improvement
even with this over head is still massive and we can deal with it
internally later.
* The symbol visibility and naming comments raised in the thread need
to be dealt with. To sum up there is 3 kinds of symbols/names :
- Global functions / structures: Those that either appear in the
header or that are visible when doing an objdump on the resulting .so
. Those all need the osmo_ prefix
- Internal to the lib: Those that are accessed between several
files in the lib. Those don't need an osmo_ prefix for brevity, but
they need something less conflicted than 'gen_' ... include 'viterbi'
or 'conv' or something to that effect in the name. They need to be
hidden from the outside (so they shouldn't show up in the resulting
.so), not sure about the current fvisibility situation in libosmocore
(don't know if we explicitely mark exported function or if we
explicitely mark non-exported one).
- Internal to the file: Make sure they're static, naming is fairly
irrelevant
So I'd say re-submit patch 1 and 4 first, forward ported to apply
cleanly and pass a make distcheck on current master. We'll get that
merged first, then look at integrating the SSE stuff.
Cheers,
Sylvain