Project for GSoC 2020

[dufault at hda.com]

> On Mar 14, 2020, at 14:22 , Gedare Bloom <gedare at rtems.org> wrote:
> 
> Hi Utkarsh,
> 
> On Sat, Mar 14, 2020 at 12:05 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>> 
>> I am in the middle of drafting the proposal for the memory protection project and specifying the interface, one of the things I would like to take to your feedback on is what are the functionalities that would be provided to the users, as some of the architectures provide a lot of support that others don't, should we keep that to a minimum or go with the maximum options. For example, ARM provides 4kb, 16kb, and 64kb page granules whereas others don't so either the users can be provided with the option of accessing other stacks in granules of various sizes or a common-minimum of 4kb.
>> 
>> Also, it would be very kind of you if you could help me with the previous message on this thread.
>> 
>> On Wed, Mar 11, 2020 at 8:34 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>>> 
>>> Before specifying the interface I want to take your kind feedback on what all things would need to be done in the interface.
>>> 
>>> By looking into the MMU description of ARM and x86, according to me, the implementation would have to be done in two levels-
>>> 
>>> 1. The architecture-specific part, wherein I will have to initialize the MMU(already implemented for ARM), TLB management and exception handling.
> 
> Yes. This is done simply in a few ports where needed, usually just to
> setup a 1:1 VA-PA mapping.
> 
>>> 2. The generalization part, wherein I will need to manage the thread stacks, their access permissions. Each stack should have a data structure associated with it that has the permission flags, starting address and other relevant information. For increased robustness of the thread stacks, every time a context switch takes place we will have to set up the page tables, TLBs to map the address of the executing thread as well as that of the threads it has the permission to access.
>>> 
> 
> I think Peter's advice is sound. We have a rough version of mmap
> implemented. It has a few problems and isn't completely functional for
> all use cases. The main question to consider as we move forward is
> whether to allow n:1 VA-PA mappings, which implies a non-linear
> address space. I think you will need to do some research about that
> topic. I don't think it is a great idea though, since AFAIK it
> requires an MMU to implement such mappings so if there is just an MPU
> then things may break (or work in weird ways).
> 
> 

The decision about memory protection unit versus memory management unit is essential to decide how this should proceed.  I believe we should require only an MPU, a lot of the discussion would require an MMU.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.