Interested in GSoC 2017 Project: Memory Protection.

[Gedare Bloom]

On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat <
h2015081 at pilani.bits-pilani.ac.in> wrote:

> Hello folks,
>
> I am Abhimanyu Rawat, a Computer Science Masters degree student from BITS
> Pilani Campus, India. I found Memory Protection project #2904
> <https://devel.rtems.org/ticket/2904> very interesting and vital for the
> the RTEMS. Among the lots of projects listed on the ideas page, Memory
> Protection draws me to RTEMS as it's a very challenging project and I would
> thoroughly enjoy working on it. I am a really enthusiastic person who would
> like to contribute to the project. I have previous experience in C, C++ and
> Python etc.  At present I am an intern at EMC ^2 where I am working on
> DataDomain Operating system, building configuration tool for the latest
> DDOS software update. I have also lead a BITS-Stanford inter-university
> project, where my team worked on Django based project with an inbuilt
> authorization tool + chat application etc. I usually help my friends with
> their projects as well.
>
> When does your internship complete, and when does your school year begin
again?


> As required, I went through the initial brief about the project and I
> think it would be a valuable addition to RTEMS. Also, I have completed the
> https://devel.rtems.org/wiki/GSoC/GettingStarted, and configured and
> Built RTEMS for SPARC/erc32. Subsequently, I have the snapshot of the
> terminal showing my name and the GSOC text as pictured here
> <https://devel.rtems.org/attachment/wiki/GSoC/GettingStarted/SPARC-SIS-HelloWorld-Modded.png>.
> Kindly tell me how to send the proof of the terminal and the diff file as
> required.
>
> Send to me by email is fine.


> It would be great if you can give me some pointers about the structure of
> the project and the direction I should pursue.
>
> Have a look at the current approach taken to provide low-level support for
the MMUs in the ARM bsps. You can find this looking in the source tree via
c/src/lib/libbsp/arm/* with most of the relevant parts in the shared
subdirectory there, where each BSP defines a table of statically-configured
MMU initialization.

This is where the prior work has pretty much left off. Remaining items in
this project area include:
* Making a uniform approach to MMU/MPU setup across architectures
* Supporting dynamic changes to MMU/MPU configurations
* Leveraging dynamic MMU/MPU enforcement to create a mid-level memory
management layers. Various proposals have been designed and implemented in
the past that can be studied.
* Creating generally useful memory protection schemes such as per-task
stack protection that can be enabled by applications with simple "switch it
on" type of logic.
* Creating an application-layer interface for memory protection management
at a finer granularity / with more application-level logic to control than
the "generally useful" approaches would need.

Overall, I look forward to working with the community and improving my
> skills by actively contributing to the project(in long run also).
>
> *Closing with thank you and warm Regards,*
>
> *Abhimanyu Rawat*
> *M.E. Computer Science, *
> *CS/IS Department, BITS Pilani, Pilani Campus*
> *Email - h2015081 at pilani.bits-pilani.ac.in
> <h2015081 at pilani.bits-pilani.ac.in> / abhimanyurawat at yahoo.com
> <abhimanyurawat at yahoo.com>*
> *Phone. 08930399302 (call/Whatsapp), 09466899302*
>
>  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
> ᐧ
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170309/ba4c137a/attachment-0002.html>