Thanks for the tip. I'd be curious to have a developer explain the work involved in porting applications to no-MMU CPUs with examples.

Besides the fork/vfork, there's also the issue of dynamic memory allocations, where an application that makes too many calls to malloc/free can end up fragmenting RAM so bad that the only solution is to kill/restart the app or even reboot the appliance.

Does someone know of an application that would watch memory on the Atcom, and if it detects too much fragmentation, send an e-mail, and reboot the device?

It doesn't use a C library at all. Some features were moved out of the kernel and into user space to lessen the need for such routines and this resulted in the creation of klibc, which can be used to build the programs you will find on a typical initramfs.

uClinux used to be a fork but has long since been merged into mainline. Now it basically means Linux built for an MMU-less system.

admin wrote:

I've checked in the code and it seems only app_dahdiras.so is problematic.
Does your Asterisk fail with app_dahdibarge.so and app_dahdiscan.so?

admin wrote:

Anyone willing to test patched app_dahdiras.so?

Hi Gilles,

Well Asterisk now a days is getting pretty complex.
It is not always trivial to me to study the algorithms behind.
So in most of the cases I am indeed consider only forks.
And the most of time is actually spent in make files.

In some more rare cases like Asterisk DSP, Spandsp , Attrafax, LEC etc
I/we have put some time on speed optimizations as the DSP code is usually where the CPU is spending the most.

I believe that there are lot of room for memory adjustments in Asterisk. As you know uClinux memory management is susceptible to memory fragmentation. In addition we don't have that much memory here as it is available on the PC.

However right now I can not afford spending very much time on this.
It's not that I don't want to

Best Regards
Dimitar