[PATCH 1/2] Add convolutional code generators for CS2/3

Harald Welte laforge at gnumonks.org
Wed Apr 20 12:42:34 UTC 2016


Hi 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)


More information about the OpenBSC mailing list