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/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Holger,
On Wed, May 17, 2017 at 11:00:06PM +0800, Holger Freyther wrote:
> >>> * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from
> >>> libosmocore.git (plus an embedded 'malloc' like umm_malloc)
> >>
> >> Why do we need this hack (pseudotalloc)?
> >
> > Because talloc is large both in terms of runtime memory overhead (for
> > each allocation) and in terms of code footprint,.
>
> related to that. How confident are you we don't rely on the hierarchical
> feature of talloc inside the libosmo* (or your more narrow list)?
Not libosmo* in general, but just libosmo{core,gsm,dsp,crypt,codec}.
However, I think we already use it in some places, although I don't
think we *rely* on it). So e.g. in osmo_fsm if you allocate child fsm's
from a parent, the children get the parent as context. However, the fsm
code itself doesn't rely on automatic free()ing of children.
There are also other features like a destructor callback which we don't
use anywhere AFAIK.
> Maybe we add some kind of runtime test/probe for that?
That could be an idea, but then that would come as a runtime overhead on
the non-embedded builds?
I think it's not really something to worry too much about it, given that
memory leaks in tiny embedded microcontrollers are found *very* quickly.
If there was a leak of some sort, chances are high that you catch it
already after a handful of allocations due to OOM.
It's also questionable whether some of the more complex constructs like
FSMs are going to be used in such environments to begin with. I think
even the logging system in its current form might want some
simplification if we want to use it there. Also, the timers could do
without rb-tree to reduce code footprint, ...
Yes, it's not nice to have that kind of possibillity for hidden
errors, but at least I'm happy with it, and there are not too many
people working on simtrace and related firmware anyway...
--
- 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)