GAPK status update
laforge at gnumonks.org
Sun Dec 3 19:11:58 UTC 2017
[as you requested a response on IRC, sorry for dropping the ball]
On Sun, Sep 10, 2017 at 04:52:55PM +0300, Vadim Yanitskiy wrote:
> 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?
I think it wasn't fully validated yet, so I think unless somebody hacks up
a test suite or some other means that make us confident that the MMX optimized
version produces the same results as the standard one, we shouldn't merge it.
> > 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.
Thanks, this would indeed be very useful (also to validate the MMX code as
> What do you think about adding GAPK to Gerrit?
Fine with me. But then, it's Sylvain's project and I wouldn't want to do
anything to it that he isn't asking for / approving of.
- 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 baseband-devel