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/.
Thomas Tsou tom at tsou.ccOn Wed, Jul 10, 2013 at 2:26 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >>> I don't foresee >>> any issues with a slight change in the API of libosmocore if it is >>> justified - just send an RFC/patch to the OpenBSC mailing list and it >>> will be reviewed. > > I _do_ see an issue with ABI and/or API change. > > The conv code is used in many projects with a bunch of different code > so any change would need to have a very good justification of why it's > needed and should be absolutely necessary. This was the issue I was trying to raise. The patch (that doesn't exist) for the API change on osmo-bts alone is huge. I don't like any API breaking changes, and I have limited interest in making changes to osmo-bts. I do like compatibility layers though. > Also, it should be obvious but any change in libosmocore must stay > compatible with all codes that have been supported until now and not > just a subset of GSM/LTE specific codes. Aside from testing all the various combinations, I'm less concerned about structural (non-API) compatibility. The convolutional codes are defined by the trellis structure or, equivalently, shift register and generator polynomials. The Viterbi algorithm is fundamentally the same in all cases. Unless there are some truly bizarre cases, which you would know more about than I do, I see this as less of an issue. > All the GSM channel coding will also be moving to libosmocore soonish > to allow usage in other projects so keeping some specific stuff in > osmo-bts will not be a viable option for long. Leaving aside LTE code, the implementation in question only exists in the posted test cases. Thomas