Hi Harald and Craig,
select.c:27:24: fatal error: sys/select.h: No such file or directory #include <sys/select.h>
I have the same issue with:
gcc-arm-none-eabi 4.8.2-14ubuntu1+6 binutils-arm-none-eabi 2.24-2ubuntu2+4 libnewlib-arm-none-eabi 2.1.0-3
- 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)? What if we could cross-compile libtalloc too, and link it against core?
- have an (optional?) osmocom-bb makefile step to git clone + configure
- make install libosmocore
Great idea! What about to have libosmocore as a git submodule inside OsmocomBB (like OpenCL headers in hashcat)?
Also, I think it would be good to make libosmocore more modular, because it could allow us to create more flexible builds (e.g. to compile only what we need, not a whole library). This makes sense in case of low RAM / ROM embedded systems. What do you think?
With best regards, Vadim Yanitskiy.
Hi Vadim,
On Wed, May 17, 2017 at 01:47:22PM +0300, Vadim Yanitskiy wrote:
Hi Harald and Craig,
select.c:27:24: fatal error: sys/select.h: No such file or directory #include <sys/select.h>
I have the same issue with:
gcc-arm-none-eabi 4.8.2-14ubuntu1+6 binutils-arm-none-eabi 2.24-2ubuntu2+4 libnewlib-arm-none-eabi 2.1.0-3
Ok, so I'll have some homework to check build in a Debian stable VM and make that work. Will let you know once I'm done with that.
- 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,.
What if we could cross-compile libtalloc too, and link it against core?
That's possible, but we're talking about microcontrollers with something like 16kBytes of RAM in total, or maybe less. You cannot afford that amount of overhead.
- have an (optional?) osmocom-bb makefile step to git clone + configure
- make install libosmocore
Great idea! What about to have libosmocore as a git submodule inside OsmocomBB (like OpenCL headers in hashcat)?
I'm not sure if we'd want that. I haven't really worked much with submodules yet, though, so my position is not a strong one here.
Also, I think it would be good to make libosmocore more modular, because it could allow us to create more flexible builds (e.g. to compile only what we need, not a whole library). This makes sense in case of low RAM / ROM embedded systems. What do you think?
linking statically with -ffunction-sections and -fdata-sections will result the linker in garbage collecting (removing) any functions that are not used. So I don't think there is any need for a more modular library, to be honest.
On 17. May 2017, at 22:08, Harald Welte laforge@gnumonks.org wrote:
Hi Vadim,
Hey,
- 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)? Maybe we add some kind of runtime test/probe for that?
holger
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...
baseband-devel@lists.osmocom.org
-
Harald Welte -
Holger Freyther -
Vadim Yanitskiy