Application programming consideration for MMU less architecture which has embedded Linux running.

Hi sg,

You are right about the fork and sbrk issues. This means your classic multi process unix applications that fork to provide a new thread don't work properly. Samba for instance needs to be run from inted rather than forking a copy of itself.

Also applications can't share code, a new copy of the application must be loaded in to ram for each new instance of the application.

Some kernel features that rely on memory mapping don't work. cramfs is an example, but I'm sure there are others.

On the plus side, because of the design of the ARM cache architecture your context switch time will be improved (see

BTW I didn't realise there were any ARM 10 architectures without an MMU. What CPU are you using?

Cheers

Matt

Here the scheduler does not need to reprogram the MMU when switching between the threads of the application and thus the cache performance should not be harmed.

-Michael

AFAIK, the way Linux starts a program is first fork the running task to create a new process and then one of the processes replaces it's memory by the new code from the elf file. between fork and replace the program usually will only write some bytes to it's stack and thus cause a "lazy copy" of a single memory page.

In µCLinux, (v)fork would need to copy the complete active memory of the process, as the OS can't know if the new process might write to it. When replacing the new content might or might not fit into the old space. This would lead to horrible performance (unnecessary copying) and memory holes in physical address space (something impossible by design in non µC).

How can this work ?

-Michael