This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
>>>>> "Chris" == Chris Waters <c.waters@celsius.co.nz> writes: Chris> From what I can see at the moment ecos provides no support Chris> for memory protection. Does anyone have any feel for how Chris> easy/hard it would be to add memory protection to the Chris> kernal for processors that provide it? The question here is exactly what you want memory protection for? The current eCos system is oriented towards multi-threaded applications rather than multitasking. It is assumed that the application consists of multiple threads which interact through a single shared address space, using appropriate synchronisation primitives such as mutexes and condition variables to control access to this shared data. In this model memory protection makes little sense (although some useful debugging tricks become possible). Memory protection is appropriate for a different type of system where there are multiple tasks or processes in separate address spaces, and interaction between the processes happens via e.g. pipes and mmap()'d regions. There are some very significant overheads associated with this model. Enabling the MMU properly requires significant code overheads becausing initializing and managing an MMU is non-trivial. There are data overheads because you need page tables etc. There are some run-time performance penalties associated with memory accesses. Typically interactions between separate processes require one or more system calls and hence crossing protection boundaries, which is expensive. Finally kernel calls usually have to involve a system trap which adds more overhead and which makes it much more difficult to eliminate functionality that is not actually needed by the application. The current version of eCos is intended to support the deeply embedded part of the market, without precluding more advanced applications. The assumption has to be that cpu cycles and all types of memory will be in short supply, and many applications would not want to enable the MMU even if support was available. Therefore we have not yet implemented any form of memory protection in eCos, we have concentrated our efforts on other parts of the system. On some architectures it is necessary to a do a certain amount of MMU manipulation to get e.g. the cache working, see the PowerPC MPC860 HAL package for an example. It should be possible to hook into that and set up a particular address map that meets the application's requirements - the current release would need a little bit of tweaking for this. In the medium to long term we are likely to add some support for MMUs. This will be configurable so that application developers can examine the costs and the benefits involved, and decide for themselves whether or not it is worthwhile. There are actually a number of possible uses for MMUs: 1) it provides a way of doing automatic stack extension with relatively low overheads. This is useful for more complicated applications where it may be too difficult to determine stack requirements by static analysis. It does restrict stack sizes to multiples of the hardware page size. 2) if there is some sort of access to the outside world, e.g. via an internet connection, it is possible to download system patches and set up the MMU so that some bits of the system get executed from RAM rather than from ROM. For some applications this can provide a cost-effective alternative to flash memory. 3) if the ROM is a scarce resource then it is possible to store some of the code in a compressed form, decompressing it into RAM as and when required. The MMU provides a way of detecting accesses to code that is not currently available in RAM. 4) limited protection support, primarily for debugging purposes, for example the ability to invalidate certain parts of the address space like location 0. Bart Veer // eCos net maintainer