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/.
Alexander Chemeris alexander.chemeris at gmail.comHi Thomas, Sylvain, Recent activity around convolutional coding has reminded me about this lost diamond. Just wondering if there is a chance to resolve the critical issues and get this merged? On Sat, Aug 1, 2015 at 12:16 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Ok, 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 -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co