Interested in GSoC 2017 Project: Memory Protection.

Thu Mar 16 17:05:55 UTC 2017

Hello Dr. Bloom,

Sorry for writing after a big gap( was busy with a product integration),
although I found time to go through the pointers you put together for me,
thanks they were really helpful in getting an idea about the project and
how to process everything in time.

I noticed that all the existing work on MMU is not moving very fast like
other supporting components for RTEMS, last year too no one was selected to
do MMU project #2904. I know only one guy applied but the proposal was not
quite promising. But trust me, all that doesn't make it any less desirable
for me to take it. Now, I have a few questions:

On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom <gedare at rtems.org> wrote:

>
>
> 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  selectively pointed towto 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.
>

You selectively pointed towards the c/src/lib/libbsp/arm/* shared
subdirectory where some BSP's has low level code for MMU configuration, I
found ome cache code too. And trying digging deep to build a common
understanding of different BSP MMU code. The code initally is quite hard to
understand but as a unit what task is taking place is I can understand
like, data cache and line cleaing etc. Therefore I would request you to
provide me a documented code review or process guide( if available) so that
I can develop something to test the MMU code changes/patches, otherwise I
will have to brute force the search. As from this point I want to move fast
and reflect the my progress.

>
> 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
>
It seems nice to have a low level design which can point out the mutual
modules such as initialising the registers, stack and memory lines etc. For
this I think underying functionality have to be completed first or complete
the remaining pieces in existing code and then move bottom up.

> * 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.
>
When you say dynamic changes, it means application level memory proection,
space quota management etc. ? I know you should be having a full list, so l
am willing to hear all that and then decide which work should be done first
and how I propose to do it.

> * 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.
>
> Ok this is exciting stuff that can be pushed first, the memory block or
segement(or whatever you say to a chunk but mostly I went through thesis
material online which denotes it as in different terms/name ) access
related control can be hacked together to provide the enclaved type of
execution for the application task. We can discuss more about it and how
much existing code base so far support this proposed project area.

I look forward, to hear what is your take on them, and last but not the
least, thanks for the warm reply, it already makes me feel home with the
community.

> 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/20170316/fb104f33/attachment-0002.html>