<div dir="ltr">Sir,<div><br></div><div>I have gone through <a href="https://homes.cs.washington.edu/~levy/opal/opal-tocs.pdf">https://homes.cs.washington.edu/~levy/opal/opal-tocs.pdf</a>, where the protection approach in Opal Operating System is provided. As per my understanding of the paper, I have tried to extract the memory protection part and have written a blog on it: <a href="http://ajrealtime.blogspot.in/2018/04/sharing-and-protection-in-single.html">http://ajrealtime.blogspot.in/2018/04/sharing-and-protection-in-single.html</a>. </div><div>Opal is a single-address-space operating system, and in this paper, a detailed description of protection is provided which I found quite useful for getting a good idea which can be implemented in RTEMS too. </div><div>I request you to please have a look at the write-up written by me after understanding this paper and also please guide me what should be my next step to proceed with the project. </div><div><br></div><div>Thanks and Regards</div><div>Abhinav Jain</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 24, 2018 at 12:36 AM, Abhinav Jain <span dir="ltr"><<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sir,<div><br></div><div>I have researched about the current MMU support available in RTEMS and I have mentioned about it in the proposal. Also as per your guidance, I have omitted the idea of developing memory protection for architectures not having MMU, rather I will give my full focus to developing MMU support for RISC -V architecture.</div><div>I request you to please review the proposal and guide me if some changes are to be made to this, or if I should work on some other architecture. I am researching more about the difference in MMU in RISC -V and PowerPC and ARM, for which the MMU support is already available in RTEMS.</div><span class=""><div><br></div><div><a href="https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/edit?usp=sharing" target="_blank">https://docs.google.com/<wbr>document/d/<wbr>1boKGnnzQGCzxIVqBVMWvK7OFJTvWK<wbr>zWDXj1EvuEuq5o/edit?usp=<wbr>sharing</a><br></div><div><br></div><div>Thanks and Regards</div><div>Abhinav Jain</div><div><br></div></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 17, 2018 at 1:29 PM, Abhinav Jain <span dir="ltr"><<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sir,<div><br></div><div>Thanks for the guidance and feedback. I have shared the draft proposal through GSoC application. I will make the changes as per your suggestions and will add the details mentioned by you.</div><span><div><br></div><div>Thanks and Regards</div><div>Abhinav Jain</div></span></div><div class="m_8424065201618349029HOEnZb"><div class="m_8424065201618349029h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 17, 2018 at 12:47 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">high-level comments:<br>
<br>
* add citations to relevant literature that you used for inspiration.<br>
* start to write a design plan for the bsp-level framework you envision.<br>
* it would be a good idea to review the existing mmu support in RTEMS.<br>
* link to this google doc as your "Draft" from your GSoC application,<br>
and also upload an initial "Final" pdf, which you can continue to<br>
revise.<br>
<span class="m_8424065201618349029m_-3143646963574096468HOEnZb"><font color="#888888"><br>
Gedare<br>
</font></span><div class="m_8424065201618349029m_-3143646963574096468HOEnZb"><div class="m_8424065201618349029m_-3143646963574096468h5"><br>
On Fri, Mar 16, 2018 at 2:48 PM, Abhinav Jain <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>> wrote:<br>
> Sir,<br>
><br>
> I have prepared a draft proposal for GSoC 2018 as suggested by you.<br>
> I request you to please guide me whether I have made it correctly or not,<br>
> whether I have written some big plans or more things can be included.<br>
><br>
> The link for the Proposal is:<br>
> <a href="https://docs.google.com/document/d/1boKGnnzQGCzxIVqBVMWvK7OFJTvWKzWDXj1EvuEuq5o/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/docume<wbr>nt/d/1boKGnnzQGCzxIVqBVMWvK7OF<wbr>JTvWKzWDXj1EvuEuq5o/edit?usp=s<wbr>haring</a><br>
><br>
> Thanks and Regards<br>
> Abhinav Jain<br>
><br>
> On Wed, Mar 14, 2018 at 10:47 PM, Abhinav Jain <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Sir,<br>
>><br>
>> Thanks for the guidance. I am studying ARM architecture and trying to find<br>
>> out the difference in it's architecture from other ones, I am trying to<br>
>> understand what can be the minimum changes to the existing framework to get<br>
>> it working on other architectures.<br>
>><br>
>> Thanks and Regards<br>
>> Abhinav Jain<br>
>><br>
>><br>
>> On Wed, Mar 14, 2018, 10:41 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>>><br>
>>> The framework exists in the rtems source code, underneath<br>
>>> c/src/lib/libbsp/arm.<br>
>>><br>
>>> Start with the GSoC template, adjust the dates, start adding details.<br>
>>> When you have a draft you can invite comments for review.<br>
>>><br>
>>> On Wed, Mar 14, 2018 at 12:18 PM, Abhinav Jain <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>><br>
>>> wrote:<br>
>>> > Sir,<br>
>>> ><br>
>>> > The description of the RoadRunner OS is mentioned in the document<br>
>>> > provided<br>
>>> > by you,<br>
>>> ><br>
>>> > <a href="https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf" rel="noreferrer" target="_blank">https://pdfs.semanticscholar.o<wbr>rg/3c92/7ed6b426fccfb203dd96be<wbr>9b7591b3744f1f.pdf</a><br>
>>> > The link (<a href="http://ieeexplore.ieee.org/document/7509439/?part=1" rel="noreferrer" target="_blank">http://ieeexplore.ieee.org/do<wbr>cument/7509439/?part=1</a>) which I<br>
>>> > mentioned in the previous mail deals with memory management scheme for<br>
>>> > the<br>
>>> > MMU-less embedded systems.<br>
>>> > If there is already a framework for ARM MMU, I will try to extend it to<br>
>>> > other architectures as much as possible, I read about various<br>
>>> > architectures<br>
>>> > in past couple of days.<br>
>>> > I request you to please provide the link to the available framework so<br>
>>> > that<br>
>>> > I can study that and proceed with its enhancement if possible. Also, I<br>
>>> > request you to please guide me for my GSoC proposal.<br>
>>> ><br>
>>> > Thanks and Regards<br>
>>> > Abhinav Jain<br>
>>> ><br>
>>> > On Wed, Mar 14, 2018 at 9:37 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>>> >><br>
>>> >> Abhinav,<br>
>>> >><br>
>>> >> Send me the linked article. Does it describe the RoadRunner OS<br>
>>> >> approach? I am not familiar with it.<br>
>>> >><br>
>>> >> Note that there is a basic framework for ARM MMU in place already.<br>
>>> >> Adoption/adaptation of it to other architectures is preferred versus<br>
>>> >> replacing it, unless absolutely necessary.<br>
>>> >><br>
>>> >> On Wed, Mar 14, 2018 at 12:03 PM, Abhinav Jain <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >> > Sir,<br>
>>> >> ><br>
>>> >> > I studied the documents provided by you in the previous mail, also I<br>
>>> >> > read a<br>
>>> >> > document from <a href="http://ieeexplore.ieee.org/document/7509439/?part=1" rel="noreferrer" target="_blank">http://ieeexplore.ieee.org/doc<wbr>ument/7509439/?part=1</a>.<br>
>>> >> > As told by you in the previous mail that the first issue to be<br>
>>> >> > solved is<br>
>>> >> > to<br>
>>> >> > provide a BSP-level framework for MMU/MPU hardware, after reading<br>
>>> >> > the<br>
>>> >> > memory<br>
>>> >> > protection in roadrunner operating system, I think that with some<br>
>>> >> > changes,<br>
>>> >> > the same concept can be implemented in the RTEMS for memory<br>
>>> >> > protection.<br>
>>> >> > I request you to please guide me whether I am right in the approach<br>
>>> >> > or I<br>
>>> >> > have to think differently.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > Thanks and Regards<br>
>>> >> > Abhinav Jain<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > On Wed, Mar 7, 2018 at 10:49 AM, Abhinav Jain<br>
>>> >> > <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>><br>
>>> >> > wrote:<br>
>>> >> >><br>
>>> >> >> Sir,<br>
>>> >> >><br>
>>> >> >> Thanks a lot for the guidance. I will study the documents provided<br>
>>> >> >> by<br>
>>> >> >> you<br>
>>> >> >> and will try to find more about this to increase my knowledge about<br>
>>> >> >> Memory<br>
>>> >> >> support.<br>
>>> >> >> I will start preparing a draft proposal as per the template<br>
>>> >> >> provided on<br>
>>> >> >> the RTEMS GSoC page.<br>
>>> >> >><br>
>>> >> >> Thanks and Regards<br>
>>> >> >> Abhinav Jain<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> On Mar 6, 2018 10:25 PM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>>> >> >><br>
>>> >> >> On Sun, Mar 4, 2018 at 1:50 AM, Abhinav Jain<br>
>>> >> >> <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>><br>
>>> >> >> wrote:<br>
>>> >> >> > Sir,<br>
>>> >> >> ><br>
>>> >> >> > Thanks for your time and consideration. I was discussing this<br>
>>> >> >> > project<br>
>>> >> >> > with<br>
>>> >> >> > Gedare Sir and he guided me, how to proceed.<br>
>>> >> >> > I am studying various things before proceeding with the code part<br>
>>> >> >> > but<br>
>>> >> >> > for<br>
>>> >> >> > now, I request you to please guide me what should be my next<br>
>>> >> >> > steps to<br>
>>> >> >> > work<br>
>>> >> >> > on this project under GSOC'18.<br>
>>> >> >> ><br>
>>> >> >> > Thanks and Regards<br>
>>> >> >> > Abhinav Jain<br>
>>> >> >> ><br>
>>> >> >> > On Sun, Mar 4, 2018 at 10:48 AM, Hesham Almatary<br>
>>> >> >> > <<a href="mailto:heshamelmatary@gmail.com" target="_blank">heshamelmatary@gmail.com</a>><br>
>>> >> >> > wrote:<br>
>>> >> >> >><br>
>>> >> >> >> On Sun, Mar 4, 2018 at 10:20 AM, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>><br>
>>> >> >> >> wrote:<br>
>>> >> >> >> ><br>
>>> >> >> >> ><br>
>>> >> >> >> > On Mar 3, 2018 12:16 PM, "Abhinav Jain"<br>
>>> >> >> >> > <<a href="mailto:jainab.2009@gmail.com" target="_blank">jainab.2009@gmail.com</a>><br>
>>> >> >> >> > wrote:<br>
>>> >> >> >> ><br>
>>> >> >> >> > Sir/Madam,<br>
>>> >> >> >> ><br>
>>> >> >> >> > I am Abhinav Jain, a second-year engineering student from<br>
>>> >> >> >> > Delhi,<br>
>>> >> >> >> > India.<br>
>>> >> >> >> > I<br>
>>> >> >> >> > have been working in Linux Kernel Development, I have been<br>
>>> >> >> >> > writing<br>
>>> >> >> >> > small<br>
>>> >> >> >> > drivers and have a good knowledge of the operating system.<br>
>>> >> >> >> > I have been studying about Memory Protection project(ticket<br>
>>> >> >> >> > #2904)<br>
>>> >> >> >> > for<br>
>>> >> >> >> > around a month and found it really interesting. I studied<br>
>>> >> >> >> > about<br>
>>> >> >> >> > POSIX,<br>
>>> >> >> >> > MMU<br>
>>> >> >> >> > support in various other architecture and the memory<br>
>>> >> >> >> > protection<br>
>>> >> >> >> > APIs<br>
>>> >> >> >> > in<br>
>>> >> >> >> > various operating systems.I have been discussing the same on<br>
>>> >> >> >> > the<br>
>>> >> >> >> > mailing<br>
>>> >> >> >> > list.<br>
>>> >> >> >> > I also solved an issue (#2522) around a week ago to gain some<br>
>>> >> >> >> > hands-on<br>
>>> >> >> >> > code.<br>
>>> >> >> >> ><br>
>>> >> >> -ENOPATCH<br>
>>> >> >><br>
>>> >> >> >> ><br>
>>> >> >> >> > Welcome aboard.<br>
>>> >> >> >> ><br>
>>> >> >> >> ><br>
>>> >> >> >> > I would like to work on the Memory Protection project under<br>
>>> >> >> >> > GSOC<br>
>>> >> >> >> > 2018,<br>
>>> >> >> >> > so I<br>
>>> >> >> >> > request you to please guide me regarding the steps to be<br>
>>> >> >> >> > followed.<br>
>>> >> >> >> ><br>
>>> >> >> >> ><br>
>>> >> >> >> > Gedare conceived of what's there be so I cc'ed him. My<br>
>>> >> >> >> > recollection<br>
>>> >> >> >> > is<br>
>>> >> >> >> > that<br>
>>> >> >> >> > there were specific things he wanted to change and when that<br>
>>> >> >> >> > was<br>
>>> >> >> >> > addressed,<br>
>>> >> >> >> > providing support for arenas on multiple architecture is<br>
>>> >> >> >> > desirable<br>
>>> >> >> >> ><br>
>>> >> >> >> +1<br>
>>> >> >> >><br>
>>> >> >> >> There might be an opportunity to port RTEMS to RISC-V's<br>
>>> >> >> >> Supervisor<br>
>>> >> >> >> Mode which will need MMU support (currently it only runs on<br>
>>> >> >> >> M-Mode<br>
>>> >> >> >> which doesn't have MMU). Both QEMU and Spike simulators support<br>
>>> >> >> >> S-Mode.<br>
>>> >> >> >><br>
>>> >> >> Start to develop a draft proposal if you have not yet, starting<br>
>>> >> >> with<br>
>>> >> >> our template. A successful proposal must contain a sound design and<br>
>>> >> >> good plan, which you will need a lot of time and feedback to<br>
>>> >> >> develop.<br>
>>> >> >><br>
>>> >> >> Don't read too much about 64-bit processor architectures and their<br>
>>> >> >> needs, since we have limited support there. The first issue to<br>
>>> >> >> resolve<br>
>>> >> >> is what kind of BSP-level interface should we provide over MMU/MPU<br>
>>> >> >> hardware, and then what can we do to use that BSP layer to provide<br>
>>> >> >> upper-layer services such as managed memory regions, better mmap()<br>
>>> >> >> support, "arena" allocators, etc. There are three views here:<br>
>>> >> >> 1. no mmu/mpu is available or it is not desired by end users.<br>
>>> >> >> 2. mmu/mpu are available, but should only be manipulated<br>
>>> >> >> statically/boot-time.<br>
>>> >> >> 3. mmu/mpu are available, and can be changed dynamically.<br>
>>> >> >><br>
>>> >> >> Managing #3 is the hardest, but accommodating 1 and 2 in any system<br>
>>> >> >> design is important. Another important concern is mmu/mpu with<br>
>>> >> >> limited<br>
>>> >> >> numbers of entries. Right now, we exist mainly in #1, and #2 is<br>
>>> >> >> only<br>
>>> >> >> used to setup a linear 1:1 memory map with all permissions enabled<br>
>>> >> >> when the MMU/MPU can't be turned off. A few projects exist here and<br>
>>> >> >> there to also restrict permissions to thread stacks with a hook in<br>
>>> >> >> the<br>
>>> >> >> context switch to change the mpu/mmu state.<br>
>>> >> >><br>
>>> >> >> Since RTEMS has no multi-process model, the existing solutions in<br>
>>> >> >> general-purpose commodity OS do not apply, but you should still be<br>
>>> >> >> familiar with how they work for sure. It would also be good for you<br>
>>> >> >> to<br>
>>> >> >> review the solutions in the commodity RTOS domain, e.g. what does<br>
>>> >> >> vxworks, safertos, threadx, etc., provides in this field.<br>
>>> >> >><br>
>>> >> >> Some relevant citations to get more relevant background:<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> <a href="https://highintegritysystems.com/downloads/white_papers/Using_an_MPU_to_Enforce_Spatial_Separation.pdf" rel="noreferrer" target="_blank">https://highintegritysystems.c<wbr>om/downloads/white_papers/Usin<wbr>g_an_MPU_to_Enforce_Spatial_Se<wbr>paration.pdf</a><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> <a href="https://pdfs.semanticscholar.org/3c92/7ed6b426fccfb203dd96be9b7591b3744f1f.pdf" rel="noreferrer" target="_blank">https://pdfs.semanticscholar.o<wbr>rg/3c92/7ed6b426fccfb203dd96be<wbr>9b7591b3744f1f.pdf</a><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> <a href="https://www.researchgate.net/publication/221033285_A_New_Approach_to_Memory_Partitioning_in_On-Board_Spacecraft_Software" rel="noreferrer" target="_blank">https://www.researchgate.net/p<wbr>ublication/221033285_A_New_App<wbr>roach_to_Memory_Partitioning_i<wbr>n_On-Board_Spacecraft_Software</a><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> >> ><br>
>>> >> >> >> ><br>
>>> >> >> >> > Thanks and Regards<br>
>>> >> >> >> > Abhinav Jain<br>
>>> >> >> >> ><br>
>>> >> >> >> > ______________________________<wbr>_________________<br>
>>> >> >> >> > devel mailing list<br>
>>> >> >> >> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> >> >> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/devel</a><br>
>>> >> >> >> ><br>
>>> >> >> >> ><br>
>>> >> >> >> ><br>
>>> >> >> >> > ______________________________<wbr>_________________<br>
>>> >> >> >> > devel mailing list<br>
>>> >> >> >> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> >> >> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/devel</a><br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >><br>
>>> >> >> >> --<br>
>>> >> >> >> Hesham<br>
>>> >> >> ><br>
>>> >> >> ><br>
>>> >> >><br>
>>> >> >><br>
>>> >> ><br>
>>> ><br>
>>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>