gsoc2013-patch and questions

[Gedare Bloom]

I am CC'ing the student who worked on this last year. I think he might
also be planning to submit a proposal about the MMU support again this
year. You two should attempt to coordinate if possible to avoid having
overlapping proposals. It may be possible that there is enough work
for two MMU related projects, but that would need to be handled with
care.

On Fri, Mar 22, 2013 at 9:01 AM, Peng Fan <van.freenix at gmail.com> wrote:
> I have a few questions about "mmu support".
> I read the low level code about mmu  of arm. The map table is statically set
> in mem_map, and the initialization code is mmu_init.
This code has not been updated with any results from past GSoC, which
did some work with the ARM MMU. I don't know how much of what was done
in the past will be kept. You do have the basic idea of what is in
place, though.

> All the code realated to mmu is here? If so, thus the flexibility is not so
> good. Because when application want to allocate a mem block,
> the attributes can not be modified.
Correct. Right now, each CPU or BSP implements its own MMU handling
just enough to make use of the physical memory. Since RTEMS is a
"single address space" operating system, the MMU does not strictly
need to do more than the bare minimum required to make the
architecture usable. For systems that require virtual memory, the
common solution is to make a one-to-one mapping between virtual and
physical memory.

> The goal of the mmu support is to implemented a well defined framework in
> which  middle level  APIs  exposed to application developers, a two level
> table implementation  and low level APIs(a common interface that can be
> called from middle level apis, I am not sure ). We can use these middle
> level  APIs to give each mem block its own attributes.
You have the right idea. Our current thinking is to figure out the
low-level infrastructure and fill in the implementations for a few
BSPs, for example some more ARM or PowerPC BSPs. Then we can think
about how applications or libraries might be able to use such
low-level support to make useful memory-related services.

The immediate goal that I see is to unify the various approaches to
MMU/MPU management (initialization with a static map, support for
dynamic changes) in the lowest level. Then we will have a clearer
picture of what kind of higher-level services are even possible to
provide.

> I am not definitely sure what I think is right.Maybe it's totally wrong.I
> just want to give myself a clear understanding.
> Thanks for your reply.
>
>
> 2013/3/22 Peng Fan <van.freenix at gmail.com>
>>
>> Hi all,
>>         I followed the "GSoC_Getting_Started" , modified init.c of the
>> hello sample and used "git diff master mybranch" to get the      patch.
>>        I am new to gsoc,so there maybe something wrong with what I have
>> done.I hope you can point it out.I will appreciate your help.I am interested
>> in "mmu support" and "improvements on smp support" listed on the "Open
>> projects" page. I am reading the mmu code written in gsoc2012. In the code,
>> it uses 1MB section as a unit.Is it coases-grained or too large? why not use
>> 4kB page as a fine-grained unit?
>>       Anyone can give me some advice about who should i contact about the
>> proposal?Thanks very much.
>>
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>