Hi 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 <lafo...@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)