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/.
Harald Welte laforge at gnumonks.orgHi Sylvain and Max,
On Wed, Apr 20, 2016 at 07:13:16AM +0200, Sylvain Munaut wrote:
> > src/gsm/conv_cs2_gen.c | 211 +++++++++++++++++++++++++++++
> > src/gsm/conv_cs3_gen.c | 299 ++++++++++++++++++++++++++++++++++++++++++
>
> Why the _gen suffix ?
>
> If they're fully automatically generated, then the build process
> should generate them, they should not be in the repo at all.
As Max confirmed they're auto-generated, indeed it should be best to use
python to generate them during build. I don't mind a build dependency
on python. We cannot affor a runtime dependency on it, but that's not
the question here.
> > +extern const struct osmo_conv_code osmo_conv_gsm0503_cs2;
> > +extern const struct osmo_conv_code osmo_conv_gsm0503_cs3;
>
> Looking at all the other symbol in osmogsm, it seems we deemed 'osmo_'
> to be redudant and so maybe "gsm0503_conv_cs2" would fit better in the
> naming scheme ?
The problems with legacy namespace pollution ;) The general rule is
'anything we add should have an osmo_ prefix'. In some cases we might
deviate from this, e.g. if we simply add a function to an existing part
of the code. We don't have any gsm0503_ prefixed symbols so far, so I'm
more in favor of the 'general rule'. But I don't have strong feelings
about it, so let's probably keep it that way.
> > +static const uint8_t osmo_conv_gsm0503_cs2_output[][2] = {
>
> All those being purely internal symbols, then don't need osmo_conv
> either
that's correct, so let's remove the prefix to avoid overly long lines.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)