GAPK status update

Vadim Yanitskiy axilirator at gmail.com
Sun Sep 10 13:52:55 UTC 2017


Hi Harald,

> I like this very much. Actually, this could even be used by
> something like the new osmo-mgw to have more or less
> generic transcoding capabilities for gsm-related codecs
> as well as PCM / G.711.

Thanks for your response! Hope my recent commits would help
to move this forward.

> * it would be nice to convert all allocations to talloc, like in other
>   osmo-* code.  This facilitates memory leak debugging.
> * rather than listing all symbols individually, you can also simply
>   export osmo_gapk_* with a wilcard.  All non-exported symbols then
>   have to avoid that prefix.  I prefer this to long lists of symbols
>   that you often forget to update when adding new functions
> * assuming you have multiple processing queues in a program in the
>   future, each queue should have a user-settable identifier which is
>   then used as a prefix in all the logging.

Done.

Only libgsmhr do use generic malloc / free calls. And I think there
is no reason to link this library against talloc as there is only
one allocation / deallocation cycle.

BTW: what about the 'laforge/mmx' branch?
Does anything prevents us from merging it to the master?

> Finally, as a personal wishlist item, I would love to see some unit
> tests that create a couple of processing queues, destroy them, check
> if the resulting encode/decodes is what was expected, and [if possible?]
> even check if allocated memory has been properly cleaned up during
> destruction of the processing queue.

Yeah, I have this idea too. But I don't have enough time
right now. Will do it as soon as it will be possible.
What do you think about adding GAPK to Gerrit?

Regarding to the proper memory deallocation check, I think it
should be possible via the talloc debugging API.


With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170910/f95e3ab3/attachment-0001.html>


More information about the baseband-devel mailing list