<br>
<br>
I have spend several days to read the code of the old project (<br>

<a href="http://code.google.com/p/rtems-mmu-support/" target="_blank">http://code.google.com/p/rtems-mmu-support/</a> ) and the document of  manual ppc and MinixPPC( <a href="http://www.minix3.org/doc/alting_thesis.pdf">http://www.minix3.org/doc/alting_thesis.pdf</a> )  <br>
<br>
here is my question<br>
what will be the main use of the MMU Support API ? OS like MinixPPC 
allow load module dynamicly, and the need to protect the page memory 
allocated to the process. But RTEMS don't support dynamic load function.<br><br>
One of my thoughts is maybe this mmu support could be used by CEXP for 
protecting the load module . For this usage,the middle level API will be
 needed . So I think it is suitable to add the task implementing the MMU
 usage in CEXP  as one of the long term goals of the MMU Support. It 
will based on the mid-level API in RTEMS and need a lot of work to do 
for the CEXP  rebuilding. <br>but even use CEXP , I think it is still necessary to change a lot of RTEMS API such as task manager . Do I  misunderstand something here? <br>I am a little confused for these now . It seems that it's not enough just adding MMU API, related API  need to be updated, right?<br>
<br>Another thought is maybe I can implement the mmu support part on arm , and supply the mid-level mmu api for further use.Is that suitable as GSOC project? If just design and implement the mid-level API( functions to create/query/remove/modify/switch the MMU context
) , the content looks a bit empty<br><br>
<table class="result_item" border="0" width="96%">
<tbody><tr><td class="numbertd" valign="top"><br>
</td><td class="Itemstyle" align="left" valign="top"><span class="trans"></span><br>
</td></tr></tbody>
</table>