Interested in GSoC 2017 Project: Memory Protection.

Sat Apr 1 02:37:52 UTC 2017

Trying to review your proposal:

1) You've to allow comments/edit so that we can give feedback.
2) The proposal is not complete, you copied the template and didn't update
all of the sections.

On Thu, Mar 30, 2017 at 8:27 AM, Abhimanyu Rawat <
h2015081 at pilani.bits-pilani.ac.in> wrote:

> Hello Dr. Bloom and other folks,
>
> I have developed an initial draft of my application, kindly review it. I
> can be more verbose in explaining the granular details regarding the
> concepts and approaches, so kindly tell me how and where I can amend the
> proposal.
>
> On Sat, Mar 25, 2017 at 12:15 PM, Hesham Almatary <
> heshamelmatary at gmail.com> wrote:
>
>>
>>
>> On Sat, Mar 25, 2017 at 6:07 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> Work on shaping your proposal document and start to plan the work you
>>> would do during the summer. This is the best way for me to collaborate is
>>> if you begin writing out your ideas in sufficient detail that I can
>>> understand and provide feedback based on where you are at.
>>>
>> +1
>>
>>>
>>> On Fri, Mar 24, 2017 at 11:26 AM, Abhimanyu Rawat <
>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>
>>>> Hello Dr. Bloom,
>>>>
>>>> I have contacted to the past contributors,  Peter and I will discuss
>>>> PowerPC and further support, next week, in the meantime, I am going through
>>>> PowerPC code and how I can build with the existing system a new bsp code
>>>> for MMU/MPU support. I will complete my application next week.
>>>>
>>>> In the meantime, any suggestions from your side are most welcome.
>>>>
>>>>
>>>> On Wed, Mar 22, 2017 at 8:57 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 22, 2017 at 11:13 AM, Abhimanyu Rawat <
>>>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>>>
>>>>>> Indeed, PowerPC code is somewhat developed, would you recommend if
>>>>>> there are some specific features in PowerPC that I should revisit? As this
>>>>>> is little confusing as some work has been done on exception handler, page
>>>>>> tables, cache already, so what should I target next and what to modify
>>>>>> first? Past developer of the PowerPC support might help if you would
>>>>>> connect me to?
>>>>>> ᐧ
>>>>>>
>>>>>> I've CC'd some of the folks who previously worked on this topic. So
>>>>> perhaps they have input for you.
>>>>>
>>>>> I think the important thing is that when we design a framework that it
>>>>> is flexible enough to accommodate the many varieties of memory management
>>>>> hardware.
>>>>>
>>>>>
>>>>>> *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*
>>>>>>
>>>>>>  ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 8:29 PM, Gedare Bloom <gedare at rtems.org>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat <
>>>>>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom <gedare at rtems.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Please prefer to try to keep general GSoC / RTEMS project
>>>>>>>>> discussions on the mailing list. Direct e-mail is ok but inefficient in
>>>>>>>>> many cases and should only be preferred for communciations of a personal or
>>>>>>>>> private matter.
>>>>>>>>>
>>>>>>>>> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat <
>>>>>>>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom <gedare at rtems.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat <
>>>>>>>>>>> h2015081 at pilani.bits-pilani.ac.in> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Gaps are normal and acceptable (until you are getting paid for
>>>>>>>>>>> work :)). You should also expect to have gaps in responses from developers
>>>>>>>>>>> on the mailing list, since we are also generally volunteering.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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:
>>>>>>>>>>>>
>>>>>>>>>>>> I would not recommend judging the priority/value of a proposed
>>>>>>>>>>> project based on whether or not it was done in the past. Definitely discuss
>>>>>>>>>>> with mentors, etc. This project area is a good, long-term investment for
>>>>>>>>>>> RTEMS, but it does move slowly.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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/G
>>>>>>>>>>>>>> SoC/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.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> I recommend that you start by writing a blog post about your
>>>>>>>>>>> understanding of what is implemented there. Look in the other BSPs to see
>>>>>>>>>>> what, if any, MMU code they have.
>>>>>>>>>>>
>>>>>>>>>>> Sure, setting up a medium blog to write about the bsp underlying
>>>>>>>>>> code  related to memory related operations.
>>>>>>>>>>
>>>>>>>>>>> Cache cleaning/invalidating is often tied with MMU state changes.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> The underlying functionality exists for at least cp15-based ARM.
>>>>>>>>>>> Providing the functionality for another BSP family would be a good place to
>>>>>>>>>>> start.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> * 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Dynamic here means the MMU entries can be changed at run-time
>>>>>>>>>>> after initialization. This is a building block for implementing
>>>>>>>>>>> higher-level services such as application-level memory protection and
>>>>>>>>>>> kernel-level APIs for memory management.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> * 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 prefer memory region to refer to a generic "Base+Offset"
>>>>>>>>>>> contiguous area of memory. We have discussed terminology quite often in the
>>>>>>>>>>> past. Reach out to Hesham to get some more details.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> We can't do application-level memory protection without a good
>>>>>>>>>>> understanding of the intermediate layers. We can start to design an API,
>>>>>>>>>>> but the API is not mergeable until there is a generic layer that is not
>>>>>>>>>>> tightly bound to the BSP or even CPU layers.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In case of arm-cp15  it's underlying fucntionality are far more
>>>>>>>>>> developed(i.e. initialization, interrupt handling, underlying tlb update
>>>>>>>>>> after fage faults etc.) than the rest of the bsp's, so I think we can start
>>>>>>>>>> to design an API for application-level memory protection. This way we can
>>>>>>>>>> have atleast one fully functional bsp for arm-cp 15, whose prototype can we
>>>>>>>>>> can later use to speed up the development  You think it can be a good
>>>>>>>>>> proposal or shall I go with other bsp underlying support first?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I'm concerned that any mid-level/high-level framework built on
>>>>>>>>> top of the existing low-level support for arm-cp15 will be too rigid to
>>>>>>>>> work with less feature-ful BSPs/MMU/MPU combinations. It would be good to
>>>>>>>>> have another one or two kinds of MMU/MPU supported so that the upper layers
>>>>>>>>> can be more thoughtfully designed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>  I agree with your approach of having more than one type of bsp's
>>>>>>>> with MMU/MPU support, so which one should I take on ? I mean I can work on
>>>>>>>> AT91RM9200 of ARM family, or you would suggest other archiitecture
>>>>>>>> like(PowerPC) ?
>>>>>>>>
>>>>>>>> PowerPC should be good. That was one of the targets worked on
>>>>>>> previously, so it should not be too difficult.
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> ᐧ
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> ᐧ
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Hesham
>>
>
>

-- 
Hesham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170401/bafbc06f/attachment-0001.html>